From extest-admin@lists.bell-labs.com  Mon Jan  1 06:10:22 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26837
	for <sip-archive@odin.ietf.org>; Mon, 1 Jan 2001 06:10:22 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 3EBF94466E
	for <sip-archive@lists.ietf.org>; Mon,  1 Jan 2001 05:06:43 -0500 (EST)
Subject: lists.bell-labs.com mailing list memberships reminder
From: mailman-owner@lists.bell-labs.com
To: sip-archive@ietf.org
X-No-Archive: yes
X-Ack: no
Sender: extest-admin@lists.bell-labs.com
Errors-To: extest-admin@lists.bell-labs.com
X-BeenThere: extest@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
Message-Id: <20010101100643.3EBF94466E@lists.bell-labs.com>
Date: Mon,  1 Jan 2001 05:06:43 -0500 (EST)

This is a reminder, sent out once a month, about your
lists.bell-labs.com 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, sip-request@lists.bell-labs.com) containing
just the word 'help' in the message body, and an email message will be
sent to you with instructions.

If you have questions, problems, comments, etc, send them to
mailman-owner@lists.bell-labs.com.  Thanks!

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

List                                     Password // URL
----                                     --------  
sip@lists.bell-labs.com                  TDGd      
http://lists.bell-labs.com/mailman/options/sip/sip-archive%40lists.ietf.org


From sip-admin@lists.bell-labs.com  Mon Jan  1 23:40:50 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02479
	for <sip-archive@odin.ietf.org>; Mon, 1 Jan 2001 23:40:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8660A44337; Mon,  1 Jan 2001 22:41:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 3814444336
	for <sip@lists.bell-labs.com>; Mon,  1 Jan 2001 22:40:04 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA02584;
	Mon, 1 Jan 2001 23:42:30 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBKG4>; Mon, 1 Jan 2001 23:37:01 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAF60@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Henning Schulzrinne'" <hgs@cs.columbia.edu>,
        Billy Biggs <billy@billybiggs.com>
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Outbound proxy (was: proxy routing logic)
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 1 Jan 2001 23:36:59 -0500



 

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Sunday, December 31, 2000 12:57 AM
> To: Billy Biggs
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] Outbound proxy (was: proxy routing logic)
> 
> 
> In any event, the new text should clearly state what outbound proxies
> need to do with Route headers. The 'every host removes top Route' rule
> implied in 2543/6.33 would not work with outbound proxies, 
> since the UAC
> already removed the top Route and placed it in the Request-URI. (I
> scanned the new text and it seems silent on this issue at least in
> section 'proxy processing of non-initial request'.)

My concern is that a proxy may not know its an "outbound" proxy. Worse yet,
whether its "outbound" or not may vary from request to request, and I REALLY
don't want special rules at a proxy server depending on knowing such a piece
of information. The only entity that definitively knows whether its using an
outbound proxy is the UA which sends the request there. As such, it is my
strong preference that any special route processing for outbound proxies
take place in the UA, since it already needs to do something special anyway.
In your example, Henning, the UA could simply not strip the top Route header
when sending to its outbound proxy. That solves the problem.

-Jonathan R.


---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  1 23:56:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02608
	for <sip-archive@odin.ietf.org>; Mon, 1 Jan 2001 23:56:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4465D44340; Mon,  1 Jan 2001 22:57:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id CC4B24433F
	for <sip@lists.bell-labs.com>; Mon,  1 Jan 2001 22:56:46 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA02667;
	Mon, 1 Jan 2001 23:59:10 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBKH2>; Mon, 1 Jan 2001 23:53:41 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAF61@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Jacek_Grabiec@3com.com'" <Jacek_Grabiec@3com.com>,
        sip@lists.bell-labs.com
Cc: billy@billybiggs.com, hgs@cs.columbia.edu,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>, rfairlie@nuera.com,
        jhornsby@ubiquity.net, vkg@lucent.com
Subject: RE: [SIP] Proxy Routing Logic
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 1 Jan 2001 23:53:39 -0500

There is a lot going on in this thread, so let me attempt to summarize some
of the issues raised. The primary question, it seems, is the required
processing at proxy foo.com when it receives a request for
sip:user@host;maddr=foo.com. Does it pop the top Route header, if there is
one, and use that? Or, does it send it to user@host first? If there is no
route header, then what does it do? Does it send 404? Proxy to user@host? 

1. It was my proposal that the UA should remove the maddr parameter before
sending to foo.com, and then the foo.com proxy would pop the top route
header and send the request there. Billy strongly objected to this, as he
wanted the maddr to be there so that transparent proxies could know the
destination ip address of the request without needing to look at actual
destination IP address of the packet. 

2. Jacek was concerned about UAs that use local outbound proxies, and who
did not have DNS support. How would they know whether the maddr, if a domain
name, was pointing to their outbound proxy or not? In one case, the maddr
would need to be stripped, and in the other case, not.


To comment on the primary issue, ignoring the Route header if the request
URI domain is not your own, and sending it to that domain first, is
dangerous, IMHO. Thats because, nearly as I can tell, it completely breaks
the existing usage of record-routing. In the existing usage, a proxy copies
the request URI in the request into the record-route, and adds its own
maddr. Requests in the reverse direction will only get routed correctly
through that same set of proxies IFF each proxy uses the top route header no
matter what. If proxies start to only sometimes use them, we will end up
with incorrectly routed requests. 

So, I would modify my proposal to satisfy some of the other requirements:

1. If there is a Route header in a request, that ALWAYS takes priority for
routing the request.
2. If there is none, and the request URI has a domain NOT matching that of
the server, but the address/domain in the maddr does, the server forwards to
the domain in the userhost portion of the R-URI. If the neither the maddr or
userhost have an ipaddress/domain matching the proxy, the proxy sends the
request to the address in the maddr. Stripping of maddr is optional.

Billy had concerns about stripping of maddr to handle transparent proxies.
This is completley bogus, IMHO. These transparent proxies would already need
to handle the far more common case where there was never an maddr to begin
with. Furthermore, I see no burden whatsoever with obtaining the destination
IP address from the packet, remembering it, and resending the request there
once the transparent proxy has done its thing.

-Jonathan R.






 

> -----Original Message-----
> From: Jacek_Grabiec@3com.com [mailto:Jacek_Grabiec@3com.com]
> Sent: Friday, December 29, 2000 6:44 PM
> To: sip@lists.bell-labs.com
> Cc: billy@billybiggs.com; hgs@cs.columbia.edu; 
> jdrosen@dynamicsoft.com;
> rfairlie@nuera.com; jhornsby@ubiquity.net; vkg@lucent.com
> Subject: [SIP] Proxy Routing Logic
> 
> 
> 
> 
> Jonathan Rosenberg wrote:
> >> -----Original Message-----
> > >From: Billy Biggs [mailto:Billy_Biggs@3com.com]
> > >Sent: Wednesday, December 20, 2000 12:54 PM
> > >To: Jo Hornsby
> > >Cc: Fairlie-Cuninghame, Robert; Jonathan Rosenberg; Keith
> > >Robinson; SIP
> > >List
> > >Subject: Re: [SIP] Proxy Routing Logic
> > >
> > >
> > >Jo Hornsby (jhornsby@ubiquity.net):
> > >
> > >>>> [Of course there will be always be different routing behaviour
> > >>>> depending on whether the request has a Route or not. [...]
> > >>>
> > >>>   Right, but this decision should only occur after you've
> > >decided if
> > >>> the request is for you.  It's very important that proxies
> > >don't just
> > >>> assume the request is meant for them if it happens to 
> appear on one
> > >>> of their listening sockets. [...]
> > >>
> > > >Maybe I'm not following properly, since I'm jumping in
> > >mid-stream, as
> > >> it were, but if I get a request, I'm going to do my best to
> > >honour it.
> > >> Maybe I won't know anything about the domain in the 
> Request-URI, but
> > > >I'll SRV and A, and hopefully everything will still be okay.
> > >
> >  > By "honour it" you mean proxy it to the destination 
> indicated by the
> > >Request-URI (and maybe add a Record-Route), right?
> > .
> > >  I just want to make sure proxies don't replace the
> > >request-URI blindly
> > >with the next Route unless the request is destined for them.
> 
> >I believe they should do this, in fact.
> 
> >Note that Jo and Robert are correct; consensus was that if a 
> local outbound
> >proxy wants to stay on the path, it should record-route. 
> This results in the
> >most flexibility (enables outbound proxies who want to see 
> only the initial
> >request).
> 
> >The more interesting issue is when a local outbound proxy 
> record routes. As
> >you pointed out, the RR inserted might look like:
> 
> >sip:jdrosen@dynamicsoft.com;maddr=outbound.proxy.com
> 
> I'm inclined to agree with Billy: maybe we should revisit the 
> idea of including
> RURI of received requests in Record-Route. It was a good idea 
> to get around the
> problem of forwarding requests if no Contact was added by UA. 
> Even then the RURI
> 
> part was used in one direction only. Now, since all UA are 
> required to add
> Contact
> adding RURI to Record-route doesn't seem to be necessary 
> (obviously I may be
> missing
> something) and ditching it would simplify a lot, including 
> solving potential
> loop
> problems.
> 
> >However, as we pointed out before, if that proxy received 
> this exact URI
> >*without* the next Route header, this would result in a loop. Billy
> >indicated he didn't want different routing of the request 
> URI dependent on
> >the presence of Route. I agree completely, and have been 
> arguing for this
> >property in Route all along.
> 
> 
> 
> >A few solutions are possible:
> 
> >1. If you send a request to a URI that contains an maddr, 
> and you end up
> >sending it to the address in that maddr, strip the maddr out 
> before sending
> >the request.
> >2. THe proxy should never had inserted this RR in the first 
> place, since
> >using it directly will cause a loop. Rather, something like Robert's
> >suggestion would be used:
> >sip:outbound.proxy.com;uri=jdrosen@dynamicsoft.com.
> 
> >-Jonathan R.
> 
> regards, Jacek Grabiec
> sip:jacek_grabiec@sip.3com.com
> 
> 

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 00:16:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02756
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 00:16:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 88DBA44337; Mon,  1 Jan 2001 23:17:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id A1E5944336
	for <sip@lists.bell-labs.com>; Mon,  1 Jan 2001 23:16:08 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA02776;
	Tue, 2 Jan 2001 00:18:40 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBK2D>; Tue, 2 Jan 2001 00:13:11 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAF62@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Billy Biggs'" <billy@billybiggs.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: SIP List <sip@lists.bell-labs.com>
Subject: RE: RR for non-INVITE call legs (was Re: [SIP] new record-route t
	ext!)
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 00:13:07 -0500



 

> -----Original Message-----
> From: Billy Biggs [mailto:billy@billybiggs.com]
> Sent: Saturday, December 30, 2000 11:20 PM
> To: Jonathan Rosenberg
> Cc: SIP List
> Subject: RR for non-INVITE call legs (was Re: [SIP] new record-route
> text!)
> 
> 
> 
> RR for non-INVITE call legs and non-INVITE requests, part 1:
> 
>   For me, a call-leg is created equally for all requests.  The final
>   response completes the leg and establishes the Route and tags.  This
>   moves the request from the one-to-many state to a one-on-one call.
> 
>   My implementation of SUBSCRIBE/NOTIFY is no different.  NOTIFYs
>   follow the established Route back and use the tags, and NOTIFYs
>   received which do not match the established legs tags are 481'd.
> 
>   Your proposal seems to be that any request other than INVITE cannot
>   create a call leg, and that the NOTIFY be sent strictly to the
>   Contact address, not follow the Route, and reset the tags.

No, no. THat is not what I had in mind. I believe it is fine to record-route
for any requests that do explicitly establish some kind of session state
with a well defined duration. In rfc2543, thats really only two - INVITE and
REGISTER. For backwards compatibility reasons, and for lack of a strong
need, I don't want to support record-routing on REGISTER. For the rfc2543
methods, that leaves only INVITE. So, where Henning has suggested:

   The record-routing mechanism only applies to {\INVITE} transactions.
   Inserting \header{Record-Route} in requests other than {\INVITE} is
   {\NOTALLOWED}.

I would say:

   The record-routing mechanism only applies to methods that establish some
kind
   of session state. For the methods defined in this specification, that is
only
   the \INVITE method. As such, inserting a \header{Record-Route} into 
   \REGISTER, \OPTIONS, \CANCEL, \ACK, or \BYE is {\NOTALLOWED}. Extensions
   that define new methods {\MUST} state whether requests with those methods
   can be record-routed.



> 
>   That's a big switch.  I'm sure everyone who has implemented (at
>   least) SUBSCRIBE/NOTIFY will have to change their code.

I think my text above addresses this. SUBSCRIBE should allow itself to be
record-routed. I am not proposing to change that.

> 
>   This also means that any firewall proxy MUST mangle the Contact
>   address for all outgoing requests other than INVITE.  

Why does this mean that? There are only three methods that have any meaning
as "initial" requests - INVITE, OPTIONS, REGISTER. INVITE is
record-routable. I have argued that since OPTIONS doesn't establish creation
of any session state, there is no real meaning in record-routing for it
anyway. REGISTER is arguable; however, a firewall proxy may need to mangle
with the contact headers there anyway, as they could contain ip addresses.


> RR for non-INVITE call legs and non-INVITE requests, part 2:
> 
>   RR/Route must be allowed for non-INVITE requests within a call, such
>   as REFER. 

Route, yes. Record-Route, no. What is the point of record-routing refer
mid-call? Record-routing INVITE mid-call is only useful for
crash-and-restart or pre-loaded routes. For REFER, it is useless for
crash-and-restart (since REFER doesn't establish a session), and also for
pre-loaded routes its not useful, since REFER doesn't establish a session. 


> This of course makes the logic really weird, since the
>   behavior for non-INVITE requests outside of a leg is different than
>   those within.

How does this follow?

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 00:52:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02912
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 00:52:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E1E134433F; Mon,  1 Jan 2001 23:53:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cybertron.div8.net (cr288451-a.flfrd1.on.wave.home.com [24.112.91.149])
	by lists.bell-labs.com (Postfix) with ESMTP id 8917F44337
	for <sip@lists.bell-labs.com>; Mon,  1 Jan 2001 23:52:52 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m14DKO0-003ErXC@cybertron.div8.net> (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Tue, 2 Jan 2001 00:53:28 -0500 (EST) 
From: Billy Biggs <billy@billybiggs.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: SIP List <sip@lists.bell-labs.com>
Subject: Re: RR for non-INVITE call legs (was Re: [SIP] new record-route t ext!)
Message-ID: <20010102005328.A7698@div8.net>
References: <B65B4F8437968F488A01A940B21982BF9AAF62@DYN-EXCH-001.dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <B65B4F8437968F488A01A940B21982BF9AAF62@DYN-EXCH-001.dynamicsoft.com>; from jdrosen@dynamicsoft.com on Tue, Jan 02, 2001 at 12:13:07AM -0500
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 00:53:28 -0500

Jonathan Rosenberg (jdrosen@dynamicsoft.com):

> >   Your proposal seems to be that any request other than INVITE
> > cannot create a call leg, and that the NOTIFY be sent strictly to
> > the Contact address, not follow the Route, and reset the tags.
> 
> No, no. THat is not what I had in mind. I believe it is fine to
> record-route for any requests that do explicitly establish some kind
> of session state with a well defined duration. [...]

  Thanks, that makes me feel better. :)     However:

> I would say:
> 
>    The record-routing mechanism only applies to methods that establish
>    some kind of session state. For the methods defined in this
>    specification, that is only the \INVITE method. As such, inserting
>    a \header{Record-Route} into \REGISTER, \OPTIONS, \CANCEL, \ACK, or
>    \BYE is {\NOTALLOWED}. Extensions that define new methods {\MUST}
>    state whether requests with those methods can be record-routed.

  To get through our firewall, we have a proxy set to Record-Route every
message with 'sip:proxy.address' and not keep any state.  This gives
immediate compatibility with any new extensions that need to work
through a firewall, such as SUBSCRIBE/NOTIFY.

  So, I would rather:

    [...] Extensions that define new methods {\MUST} state whether
    requests with those methods should be record-routed.
    Implementations {\MAY} choose to add a record-route to unknown
    methods.

> > RR for non-INVITE call legs and non-INVITE requests, part 2:
> > 
> >   RR/Route must be allowed for non-INVITE requests within a call,
> >   such as REFER. 
> 
> Route, yes. Record-Route, no. What is the point of record-routing refer
> mid-call? [...]
> 
> > This of course makes the logic really weird, since the behavior for
> > non-INVITE requests outside of a leg is different than those within.
> 
> How does this follow?

  If you don't know anything about NEWMETHOD and you statelessly add
Record-Routes, then you would want to do the same whether its a mid-call
NEWMETHOD or an initial NEWMETHOD.

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 01:32:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06586
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 01:32:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A4C1D44337; Tue,  2 Jan 2001 00:33:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cybertron.div8.net (cr288451-a.flfrd1.on.wave.home.com [24.112.91.149])
	by lists.bell-labs.com (Postfix) with ESMTP id 32E1B44336
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 00:32:23 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m14DL0A-003ErXC@cybertron.div8.net> (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Tue, 2 Jan 2001 01:32:54 -0500 (EST) 
From: Billy Biggs <billy@billybiggs.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: Jacek_Grabiec@3com.com, sip@lists.bell-labs.com, hgs@cs.columbia.edu,
        rfairlie@nuera.com, jhornsby@ubiquity.net, vkg@lucent.com
Subject: Re: [SIP] Proxy Routing Logic
Message-ID: <20010102013254.A7722@div8.net>
References: <B65B4F8437968F488A01A940B21982BF9AAF61@DYN-EXCH-001.dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <B65B4F8437968F488A01A940B21982BF9AAF61@DYN-EXCH-001.dynamicsoft.com>; from jdrosen@dynamicsoft.com on Mon, Jan 01, 2001 at 11:53:39PM -0500
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 01:32:54 -0500

Jonathan Rosenberg (jdrosen@dynamicsoft.com):

> To comment on the primary issue, ignoring the Route header if the
> request URI domain is not your own, and sending it to that domain
> first, is dangerous, IMHO. Thats because, nearly as I can tell, it
> completely breaks the existing usage of record-routing. In the
> existing usage, a proxy copies the request URI in the request into the
> record-route, and adds its own maddr. Requests in the reverse
> direction will only get routed correctly through that same set of
> proxies IFF each proxy uses the top route header no matter what. If
> proxies start to only sometimes use them, we will end up with
> incorrectly routed requests. 

  I want to understand you correctly.  Which of these is correct to you:

1.  If I am foo.com and I receive a request with RURI naming bar.com, I
    send it to bar.com REGARDLESS of whether there is a Route.

2.  If I am foo.com and I receive a request with RURI naming bar.com, I
    pop the top Route and send it there OR send to bar.com if there is
    no Route.

  I am STRONGLY for 1.  I can give many examples of where 2 will break.

> Billy had concerns about stripping of maddr to handle transparent
> proxies.  This is completley bogus, IMHO. These transparent proxies
> would already need to handle the far more common case where there was
> never an maddr to begin with. Furthermore, I see no burden whatsoever
> with obtaining the destination IP address from the packet, remembering
> it, and resending the request there once the transparent proxy has
> done its thing.

  More reasons not to ever strip the maddr:

1. The maddr may be a domain name, which means that stripping it will
   lose information.

2. In many transparent proxy situations, requests are IP'ly diverted to
   a special proxy by a non-SIP-aware router.  The SIP proxy has no way
   to know the original destination.  This works for HTTP, why not SIP?

3. Proxies on machines with many interfaces will appreciate being able
   to see which address the request was received on without opening a
   socket for each interface.

4. Routing decisions can be changed on proxies without changing the
   messages they generate.

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 05:21:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16563
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 05:21:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A73C144338; Tue,  2 Jan 2001 04:22:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from hindon.hss.co.in (unknown [202.54.26.202])
	by lists.bell-labs.com (Postfix) with ESMTP id A4AB044337
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 04:21:12 -0500 (EST)
Received: from hsssun01.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f02AMOF21607
	for <sip@lists.bell-labs.com>; Tue, 2 Jan 2001 15:52:24 +0530 (IST)
Received: from sampark.hss.hns.com (sampark [139.85.229.22])
	by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id f02AUFK11683
	for <sip@lists.bell-labs.com>; Tue, 2 Jan 2001 16:00:20 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 652569C8.003909F5 ; Tue, 2 Jan 2001 15:53:01 +0530
X-Lotus-FromDomain: HSSBLR
From: kbinu@hss.hns.com
To: sip@lists.bell-labs.com
Message-ID: <652569C8.0039087A.00@sampark.hss.hns.com>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] Proxy Authentication sequence
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 15:52:56 +0530



Hi
     I have a doubt regarding the authentication challenge-response
sequence. Consider the following call-flow:
     A proxy rejects an INVITE with a "407 Proxy Authentication Required"
response containing a challenge. The client acknowledges the response. Now
when the client sends an INVITE with the response to the challenge, does it
necessarily have to be a new call ?  The call-flows draft shows a new
call-id being used in the next INVITE. However, is it correct if the client
uses an incremented CSeq number with the same call-id in the new INVTE
containing the response to the challenge ?

-Binu



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 07:43:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17247
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 07:43:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0C83744337; Tue,  2 Jan 2001 06:44:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by lists.bell-labs.com (Postfix) with ESMTP id E96CB44336
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 06:43:50 -0500 (EST)
Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f02ChdV17972
	for <sip@lists.bell-labs.com>; Tue, 2 Jan 2001 14:43:39 +0200 (EET)
Received: from esebh11nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tac158f2216f50dc5f551e@esvir02nok.nokia.com>;
 Tue, 2 Jan 2001 14:43:38 +0200
Received: by esebh11nok with Internet Mail Service (5.5.2652.78)
	id <ZPYLNQFR>; Tue, 2 Jan 2001 14:43:38 +0200
Message-ID: <EF9802A00654D411934E00508BAD76CC1000B3@eseis13nok.ntc.nokia.com>
From: aki.niemi@nokia.com
To: kbinu@hss.hns.com
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Proxy Authentication sequence
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 14:43:28 +0200


> Hi
>      I have a doubt regarding the authentication challenge-response
> sequence. Consider the following call-flow:
>      A proxy rejects an INVITE with a "407 Proxy 
> Authentication Required"
> response containing a challenge. The client acknowledges the 
> response. Now
> when the client sends an INVITE with the response to the 
> challenge, does it
> necessarily have to be a new call ?  The call-flows draft shows a new
> call-id being used in the next INVITE. However, is it correct 
> if the client
> uses an incremented CSeq number with the same call-id in the new INVTE
> containing the response to the challenge ?
> 

Incrementing CSeq is not only correct behaviour, but also required
behaviour. According to RFC2543, a UAC resubmitting a request with its
credentials after a 401/407 MUST increment the CSeq. This way the requests
stay in the same call-leg, and servers can have per request challenges,
which e.g. time out after a while.

Resubmitted requests after 401/407 with a new call-id will result in servers
endlessly sending "fresh" credentials to the client.

Cheers,
Aki

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 09:57:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18520
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 09:57:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0D13744337; Tue,  2 Jan 2001 08:58:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ws9.cdotb.ernet.in (unknown [202.41.72.121])
	by lists.bell-labs.com (Postfix) with ESMTP id 7C0FE44336
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 08:57:35 -0500 (EST)
Received: from cdotb.ernet.in (IDENT:rprakash@nirvana.cdotb.ernet.in [192.168.51.210])
	by ws9.cdotb.ernet.in (8.9.3/8.9.3) with ESMTP id UAA14038
	for <sip@lists.bell-labs.com>; Tue, 2 Jan 2001 20:20:55 +0500 (GMT+0500)
Message-ID: <3A51EBD6.F7A5BE5@cdotb.ernet.in>
From: Prakash R <rprakash@cdotb.ernet.in>
Reply-To: rprakash@cdotb.ernet.in
Organization: C-DOT (Center for Development of Telematics)
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] SIP Grammar?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 02 Jan 2001 20:25:18 +0530
Content-Transfer-Encoding: 7bit

Where can I find the SIP grammar? Is it available in a form suitable
from where I can build a yacc grammar easily?

NOTE: I'm new to this list. If this question has been asked earlier,
could somebody send me an email directly with the answer?

- Thanks in advance,
-- 
Prakash R
Co-ordinating Engineer, Internet Telephony Group
===========================================================================
C-DOT (Centre for Development of Telematics)
71/1, Sneha Complex, Miller Road, Bangalore - 560052, India
Email:rprakash@cdotb.ernet.in, Phone:+91-80-2263399, Fax:+91-80-2263256
===========================================================================

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 10:01:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18585
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 10:01:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 62FD54433F; Tue,  2 Jan 2001 09:02:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id A9B854433F
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 09:01:29 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA15765;
	Tue, 2 Jan 2001 10:01:15 -0500 (EST)
Message-ID: <3A51ED3C.78EA4C6B@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: Billy Biggs <billy@billybiggs.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] Outbound proxy (was: proxy routing logic)
References: <B65B4F8437968F488A01A940B21982BF9AAF60@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 02 Jan 2001 10:01:16 -0500
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Sunday, December 31, 2000 12:57 AM
> > To: Billy Biggs
> > Cc: sip@lists.bell-labs.com
> > Subject: Re: [SIP] Outbound proxy (was: proxy routing logic)
> >
> >
> > In any event, the new text should clearly state what outbound proxies
> > need to do with Route headers. The 'every host removes top Route' rule
> > implied in 2543/6.33 would not work with outbound proxies,
> > since the UAC
> > already removed the top Route and placed it in the Request-URI. (I
> > scanned the new text and it seems silent on this issue at least in
> > section 'proxy processing of non-initial request'.)
> 
> My concern is that a proxy may not know its an "outbound" proxy. Worse yet,
> whether its "outbound" or not may vary from request to request, and I REALLY
> don't want special rules at a proxy server depending on knowing such a piece
> of information. The only entity that definitively knows whether its using an
> outbound proxy is the UA which sends the request there. As such, it is my
> strong preference that any special route processing for outbound proxies
> take place in the UA, since it already needs to do something special anyway.
> In your example, Henning, the UA could simply not strip the top Route header
> when sending to its outbound proxy. That solves the problem.

Depends on what your use of 'outbound proxy' is. If only UAs can use
outbound proxies, proxy-removes-Route works. In the acme.com example I
raised, the 'interior' host (sales.acme.com) also uses an outbound
proxy, the acme.com proxy. For firewall traversal, this may well be
needed. Maybe the general rule of "if you're using an outbound proxy,
don't touch the Route header" might work. Presumably, each host knows
whether it is using an outbound proxy. May still cause some difficulty
if the Route header points to the outbound proxy.

However, in any case, the UA would have to use the regular destination
URL (typically, To) in the R-URI.

Definitely needs to be discussed in the text.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 10:03:12 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18599
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 10:03:12 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1D6B544349; Tue,  2 Jan 2001 09:03:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id AFA0A44337
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 09:01:59 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA15798;
	Tue, 2 Jan 2001 10:01:46 -0500 (EST)
Message-ID: <3A51ED5A.1E7D8A9F@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Jacek_Grabiec@3com.com'" <Jacek_Grabiec@3com.com>,
        sip@lists.bell-labs.com, billy@billybiggs.com, rfairlie@nuera.com,
        jhornsby@ubiquity.net, vkg@lucent.com
Subject: Re: [SIP] Proxy Routing Logic
References: <B65B4F8437968F488A01A940B21982BF9AAF61@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 02 Jan 2001 10:01:46 -0500
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:

> 
> So, I would modify my proposal to satisfy some of the other requirements:
> 
> 1. If there is a Route header in a request, that ALWAYS takes priority for
> routing the request.

That still does not work for outbound proxies. If some distant proxy
inserts a record-route, you still have to send the request to the
outbound proxy (with the address from the Route inserted into the
R-URI). 


> 2. If there is none, and the request URI has a domain NOT matching that of
> the server, but the address/domain in the maddr does, the server forwards to
> the domain in the userhost portion of the R-URI. If the neither the maddr or
> userhost have an ipaddress/domain matching the proxy, the proxy sends the
> request to the address in the maddr. Stripping of maddr is optional.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 10:05:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18621
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 10:05:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8670744352; Tue,  2 Jan 2001 09:06:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by lists.bell-labs.com (Postfix) with ESMTP id DF82D4434D
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 09:05:28 -0500 (EST)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f02F3S118731;
	Tue, 2 Jan 2001 07:03:28 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104])
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f02F4Rb14531;
	Tue, 2 Jan 2001 07:04:27 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569C8.0052F891 ; Tue, 2 Jan 2001 07:06:15 -0800
X-Lotus-FromDomain: 3COM
From: Jacek_Grabiec@3com.com
To: sip@lists.bell-labs.com
Cc: billy@billybiggs.com, hgs@cs.columbia.edu,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>, rfairlie@nuera.com,
        jhornsby@ubiquity.net, vkg@lucent.com
Message-ID: <882569C8.0052F6DF.00@hqoutbound.ops.3com.com>
Subject: RE: [SIP] Proxy Routing Logic
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 09:07:13 -0600



Jonathan Rosenberg wrote;
>To comment on the primary issue, ignoring the Route header if the request
>URI domain is not your own, and sending it to that domain first, is
>dangerous, IMHO. Thats because, nearly as I can tell, it completely breaks
>the existing usage of record-routing. In the existing usage, a proxy copies
>the request URI in the request into the record-route, and adds its own
>maddr. Requests in the reverse direction will only get routed correctly
>through that same set of proxies IFF each proxy uses the top route header no
>matter what. If proxies start to only sometimes use them, we will end up
>with incorrectly routed requests.

I'm not sure if 'ignoring the Route header if the request
URI domain is not your own, and sending it to that domain first' breaks
anything.
I can see it may add another proxy to the path, but at least all record-routed
Proxies are on the path as well. Doing otherwise will break routing (I gave an
example
in one of my previuos postings). I would argue that proxy cannot blindly follow
logic 'replace RURI with Route' no matter what just like it does not proxy
responses
downstream if top-via doesn't match the server - it checks if it matches first.

>So, I would modify my proposal to satisfy some of the other requirements:

>1. If there is a Route header in a request, that ALWAYS takes priority for
>routing the request.
>2. If there is none, and the request URI has a domain NOT matching that of
>the server, but the address/domain in the maddr does, the server forwards to
>the domain in the userhost portion of the R-URI. If the neither the maddr or
>userhost have an ipaddress/domain matching the proxy, the proxy sends the
>request to the address in the maddr. Stripping of maddr is optional.

your 2 suggestion is really close what I would have in mind. There's also
another
scenario: where Proxy receives a request with maddr where neither maddr nor host
portion of RURI matches the server.

Let's say proxy at sip.company.com receives a requests like:

sip:abc@someone-else.com;maddr=proxy.com
.......
Route: <sip:123@yet-someone-else.com;maddr=yet-yet-someone-else.com>

As Billy pointed out you, being the proxy, don't really want to pop Route header
 blindly. I would rather
propose something along theses lines - it is really close to your 2 case (it
also takes care of scenario where
Proxy has it's own outbound Proxy which may have its own outbound Proxy etc - if
 you were to pop Route at
every hop the message would never get to the proper Proxies):
Investigate RURI first:
1)   if maddr exist and it doesn't match your domain send message to:
     - address indicated in maddr and strip maddr.
     - or, if outbound Proxy is used, to outbound Proxy and preserve maddr
     - or, return 488 if unwilling/unable to forward the request (I explained my
 reasoning for 488 in previous posting)
2)   if maddr exist and it matches your domain strip maddr and go to 3
3)   if host part of RURI doesn't match your domain send message to:
     - address indicated in host part of RURI and preserve existing RURI and
Route(s),
     - or, if outbound Proxy is used, to outbound Proxy and preserve existing
RURI and Route(s),
4)   if host part of RURI does match your domain pop first Route header and go
back to 1
     (now your RURI is whatever Route header contained).
5)   if there's no Route header do whatever you want (get contact from your
     location/registrar server most likely) and go back to 1 (now RURI is
whatever you got
     from location/registrar server)


regards, Jacek Grabiec
sip:jacek_grabiec@sip.3com.com



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 10:28:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18794
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 10:28:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 902C344337; Tue,  2 Jan 2001 09:29:01 -0500 (EST)
Delivered-To: sip@share.research.bell-labs.com
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by lists.bell-labs.com (Postfix) with SMTP id C6E0644336
	for <sip@share.research.bell-labs.com>; Tue,  2 Jan 2001 09:28:13 -0500 (EST)
Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Tue Jan  2 10:26:10 EST 2001
Received: by lists.bell-labs.com (Postfix)
	id ACB9A44380; Tue,  2 Jan 2001 10:13:00 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from daimanta.ascend.com (unknown [152.148.40.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 6372B4437D
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 10:13:00 -0500 (EST)
Received: from reddog.casc.com (reddog.ascend.com [152.148.100.22])
	by daimanta.ascend.com (8.9.3/8.9.3) with ESMTP id KAA22887
	for <sip@lists.bell-labs.com>; Tue, 2 Jan 2001 10:12:59 -0500 (EST)
Received: from lucent.com ([152.148.210.204])
	by reddog.casc.com (8.8.8+Sun/8.8.8) with ESMTP id JAA24538
	for <sip@lists.bell-labs.com>; Tue, 2 Jan 2001 09:49:19 -0500 (EST)
Message-ID: <3A51EFF6.2730E0AD@lucent.com>
From: Kim Liu <kliu@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.72 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Cc: "sip@lists.bell-labs.com." <sip@lists.bell-labs.com>
Subject: Re: [SIP] a tiny binary sip proxy protocol
References: <20001230081322.14756.qmail@mailweb7.rediffmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 02 Jan 2001 10:12:55 -0500
Content-Transfer-Encoding: 7bit

Ashhar Farhan wrote:

> i am proposing a very easily implemented, binary level protocol that can easily translate to and from sip
> signalling. the protocol is right now called STP (Sip's Tiny Proxy).

Interesting.  I have been wondering if someone would work out something more efficient for machine-to-machine signalling.

There's some potential there, but it needs to be fleshed out more.

Kim Liu
Senior Software Engineer
kliu@lucent.com


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 10:32:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18896
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 10:32:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C215144359; Tue,  2 Jan 2001 09:33:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from is1-55.antd.nist.gov (is1-50.antd.nist.gov [129.6.50.251])
	by lists.bell-labs.com (Postfix) with ESMTP id 1832244340
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 09:32:10 -0500 (EST)
Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9])
	by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id KAA14633;
	Tue, 2 Jan 2001 10:25:20 -0500 (EST)
Message-ID: <3A51F426.E6E82F36@nist.gov>
From: "M. Ranganathan" <mranga@nist.gov>
Reply-To: mranga@nist.gov
Organization: NIST advanced networking technologies group
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: rprakash@cdotb.ernet.in
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP Grammar?
References: <3A51EBD6.F7A5BE5@cdotb.ernet.in>
Content-Type: multipart/alternative;
 boundary="------------E5F714F535CB001DD3A99170"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 02 Jan 2001 10:30:46 -0500


--------------E5F714F535CB001DD3A99170
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64

If you would like to download a free, public domain parser for sip/sdp that
uses a BNF-like grammar here is a url:

http://www.antd.nist.gov/proj/iptel/

click on the nist-sip link.

If you want to check out the grammar, there is a link from the javadoc.

Regards

Ranga


Prakash R wrote:

> Where can I find the SIP grammar? Is it available in a form suitable
> from where I can build a yacc grammar easily?
>
> NOTE: I'm new to this list. If this question has been asked earlier,
> could somebody send me an email directly with the answer?
>
> - Thanks in advance,
> --
> Prakash R
> Co-ordinating Engineer, Internet Telephony Group
> ===========================================================================
> C-DOT (Centre for Development of Telematics)
> 71/1, Sneha Complex, Miller Road, Bangalore - 560052, India
> Email:rprakash@cdotb.ernet.in, Phone:+91-80-2263399, Fax:+91-80-2263256
> ===========================================================================
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932



--------------E5F714F535CB001DD3A99170
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
If you would like to download a free, public domain parser for sip/sdp
that uses a BNF-like grammar here is a url:
<p><A HREF="http://www.antd.nist.gov/proj/iptel/">http://www.antd.nist.gov/proj/iptel/</A>
<p>click on the nist-sip link.
<p>If you want to check out the grammar, there is a link from the javadoc.
<p>Regards
<p>Ranga
<br>&nbsp;
<p>Prakash R wrote:
<blockquote TYPE=CITE>Where can I find the SIP grammar? Is it available
in a form suitable
<br>from where I can build a yacc grammar easily?
<p>NOTE: I'm new to this list. If this question has been asked earlier,
<br>could somebody send me an email directly with the answer?
<p>- Thanks in advance,
<br>--
<br>Prakash R
<br>Co-ordinating Engineer, Internet Telephony Group
<br>===========================================================================
<br>C-DOT (Centre for Development of Telematics)
<br>71/1, Sneha Complex, Miller Road, Bangalore - 560052, India
<br>Email:rprakash@cdotb.ernet.in, Phone:+91-80-2263399, Fax:+91-80-2263256
<br>===========================================================================
<p>_______________________________________________
<br>SIP mailing list
<br>SIP@lists.bell-labs.com
<br><a href="http://lists.bell-labs.com/mailman/listinfo/sip">http://lists.bell-labs.com/mailman/listinfo/sip</a></blockquote>

<pre>--&nbsp;
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.&nbsp;
Tel: 301 975 3664 Fax: 301 590 0932</pre>
&nbsp;
</body>
</html>

--------------E5F714F535CB001DD3A99170--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 10:58:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19431
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 10:58:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 81A9B44338; Tue,  2 Jan 2001 09:59:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id 86A3944336
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 09:58:16 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 2 Jan 2001 15:58:05 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id PAA01393; Tue, 2 Jan 2001 15:56:29 GMT
From: "Jo Hornsby" <jhornsby@ubiquity.net>
To: "Billy Biggs" <billy@billybiggs.com>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: <Jacek_Grabiec@3com.com>, <sip@lists.bell-labs.com>, <hgs@cs.columbia.edu>,
        <rfairlie@nuera.com>, <vkg@lucent.com>
Subject: RE: [SIP] Proxy Routing Logic
Message-ID: <002401c074d4$91c3f040$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <20010102013254.A7722@div8.net>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 15:56:29 -0000
Content-Transfer-Encoding: 7bit

Billy wrote:
> 4. Routing decisions can be changed on proxies without changing the
>    messages they generate.

It's interesting that you came up with this point.

I am very much for the approach that a proxy -- well, any client
-- can send a request wherever it likes, regardless of what the
Request-URI says.  Not that I would recommend doing it lightly,
but I think this allows for incredible flexibility.

In a simple case, think of a proxy that handles tel: URLs.
It has two simple rules: if the Request-URI is a sip: URL,
do 1.4.2 magic, if the Request-URI is a tel: URL, send to
server X; in either case, do not modify the Request-URI.

If this proxy receives a request with a Request-URI beginning
tel:, then when it forwards the request, the Request-URI is
probably not helpful to the casual observer in determining
where the request is going _next_.  Does this really matter?
The Request-URI is supposed to describe the _destination_ of
the request -- as is often stated: this is one of the most
fundamental protocol invariants.

As an extension of this, I would consider it dangerous to start
second-guessing a proxy's routing decisions: what if a proxy
receives a request (Request-URI is SIP URL) with an maddr already
present, and this proxy has its own sort of "outbound proxy"?
It can't add another maddr.

The ability for a proxy to perform truly exotic routing is,
IMHO, one of the most beautiful aspects of SIP.  I would see
it as a shame to start mandating too much about what the
Request-URI should or should not look like.

Just my two.

Happy New Year. &:)


 - Jo.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 12:29:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20360
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 12:29:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 525AD4433C; Tue,  2 Jan 2001 11:30:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id F211F44337
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 11:29:07 -0500 (EST)
Received: from cowboys (IDENT:root@localhost [127.0.0.1])
	by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id XAA16821
	for <sip@lists.bell-labs.com>; Tue, 2 Jan 2001 23:35:01 -0600
Message-ID: <00b801c074e1$1946d530$ea036e3f@dynamicsoft.com>
From: "Dean Willis" <dean.willis@softarmor.com>
To: "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [SIP] Discussion of Default Timers
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 11:26:09 -0600
Content-Transfer-Encoding: 7bit


I've started to wonder about the retransmission timers recommended in 2543.

The basic assumption is that VoIP networks will have round-trip times of
less than 500ms. This seems to be a valid assumptio for the medai path, but
remember -- with SIP, the SIGNALING path is not necessarily thesame as the
MEDIA path. And the timers apply to the SIGNALING path.

Many of the architectures I'm seeing have three thousand kilometers, ten
routers, and six proxies between two SIP endpoints.  Assuming 6ms/1000km,
10ms/router, and 50ms/proxy, that works out to 418ms each way, or a total of
836ms round trip. With default settings, the originating UA is going to
resend its INVITE after only 500ms unless response is received. Everybody
wants to use stateless proxies for performance reaons. So, nearly every
INVITE gets sent twice. This can be severely detrimental to the function of
a proxy that is operating at near peak capacity -- in fact, it basically
cuts the peak capacity of a proxy in half whenever proxy chains are
configured in such a way that T1 is regularly exceeded.

There are a couple of alternatives that come to mind:

1) Deploy faster proxies.
2) Deploy 100-generating proxies at all levels to prevent timer expiration
due to downstream latency.
3) Change the default timers.

Thoughts?

--
Dean Willis




_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 12:44:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20485
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 12:44:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 37F5C44346; Tue,  2 Jan 2001 11:45:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 4C9194433C
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 11:44:46 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA23919;
	Tue, 2 Jan 2001 12:44:33 -0500 (EST)
Message-ID: <3A521381.7637207D@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Cc: "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
Subject: Re: [SIP] Discussion of Default Timers
References: <00b801c074e1$1946d530$ea036e3f@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 02 Jan 2001 12:44:33 -0500
Content-Transfer-Encoding: 7bit

Dean Willis wrote:
> 
> I've started to wonder about the retransmission timers recommended in 2543.
> 
> The basic assumption is that VoIP networks will have round-trip times of
> less than 500ms. This seems to be a valid assumptio for the medai path, but
> remember -- with SIP, the SIGNALING path is not necessarily thesame as the
> MEDIA path. And the timers apply to the SIGNALING path.
> 
> Many of the architectures I'm seeing have three thousand kilometers, ten
> routers, and six proxies between two SIP endpoints.  Assuming 6ms/1000km,
> 10ms/router, and 50ms/proxy, that works out to 418ms each way, or a total of

If you have a router that takes 10 ms, you should ask for your money
back (or, better yet, donate it to a networking museum). Obviously, you
can have queues longer than that; I would hope that in the long run,
some form of diff-serv marking will basically make signaling
queueing-free. Thus, with an alternate architecture of two proxies and
fast routers, we get 18 ms speed-of-light and 100 ms for proxies.

> 836ms round trip. With default settings, the originating UA is going to
> resend its INVITE after only 500ms unless response is received. Everybody
> wants to use stateless proxies for performance reaons. So, nearly every

It would be interesting to see how much performance is actually lost by
keeping transaction state. My perception is that our proxy spends most
of its (wall clock) time waiting for external lookups (DNS, location
database), which would presumably not depend on stateless vs.
transaction-stateful.

> INVITE gets sent twice. This can be severely detrimental to the function of
> a proxy that is operating at near peak capacity -- in fact, it basically
> cuts the peak capacity of a proxy in half whenever proxy chains are
> configured in such a way that T1 is regularly exceeded.
> 
> There are a couple of alternatives that come to mind:
> 
> 1) Deploy faster proxies.
> 2) Deploy 100-generating proxies at all levels to prevent timer expiration
> due to downstream latency.
> 3) Change the default timers.

Which obviously comes at a cost of significantly longer call setup
delays if the first packet gets lost.

> 

4) Use fewer proxies. I have a hard time seeing why you really need more
than two (outbound and inbound) proxy in most cases. This should be true
for email as well (there are two hops to the list and two from the list
to me), although there seem to be companies where email hops along
internally for various Notes/Exchange/IBM Profs translators and who
knows what else.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 12:55:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20554
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 12:55:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 822B044344; Tue,  2 Jan 2001 11:56:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 12BE14433B
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 11:55:15 -0500 (EST)
Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f02HsvK21084;
	Tue, 2 Jan 2001 11:54:57 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f02HphB06839;
	Tue, 2 Jan 2001 11:51:43 -0600 (CST)
Received: from ericsson.com (pc050188.exu.ericsson.se [138.85.50.188]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA19414; Tue, 2 Jan 2001 11:54:56 -0600 (CST)
Message-ID: <3A521601.27576023@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Cc: "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
Subject: Re: [SIP] Discussion of Default Timers
References: <00b801c074e1$1946d530$ea036e3f@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 02 Jan 2001 11:55:13 -0600
Content-Transfer-Encoding: 7bit

I agree that this is a problem and it is aggravated in the
case of wireless access where latencies are even larger.

Regarding the alternatives you list:

1) Faster proxies -- this is basically chasing rainbows. The processing
   delay can only be cut down so much and it is prone to break when
   new topologies introduce additional proxies

2) More statefull proxies -- This seems like a reasonable approach
   for many deployments (enterprise and GSTN gateways in particular)
   but of course can't be fixed by standardization, i.e. we can't
   mandate this (at least in the SIP spec)

3) Changing the default timers -- I like this approach but I think
   it isn't realistic given the current implementations. How many
   implementations hard-code this value I wonder?

I would recommend a combination of alternatives 2 and 3 for 
most architectures. Perhaps this could be part of a larger set
of recommendations in a BCP?

/sean

Dean Willis wrote:
> 
> I've started to wonder about the retransmission timers recommended in 2543.
> 
> The basic assumption is that VoIP networks will have round-trip times of
> less than 500ms. This seems to be a valid assumptio for the medai path, but
> remember -- with SIP, the SIGNALING path is not necessarily thesame as the
> MEDIA path. And the timers apply to the SIGNALING path.
> 
> Many of the architectures I'm seeing have three thousand kilometers, ten
> routers, and six proxies between two SIP endpoints.  Assuming 6ms/1000km,
> 10ms/router, and 50ms/proxy, that works out to 418ms each way, or a total of
> 836ms round trip. With default settings, the originating UA is going to
> resend its INVITE after only 500ms unless response is received. Everybody
> wants to use stateless proxies for performance reaons. So, nearly every
> INVITE gets sent twice. This can be severely detrimental to the function of
> a proxy that is operating at near peak capacity -- in fact, it basically
> cuts the peak capacity of a proxy in half whenever proxy chains are
> configured in such a way that T1 is regularly exceeded.
> 
> There are a couple of alternatives that come to mind:
> 
> 1) Deploy faster proxies.
> 2) Deploy 100-generating proxies at all levels to prevent timer expiration
> due to downstream latency.
> 3) Change the default timers.
> 
> Thoughts?
> 
> --
> Dean Willis
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 13:03:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20676
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 13:03:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 998B044343; Tue,  2 Jan 2001 12:04:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 7EC9C44337
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 12:03:40 -0500 (EST)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA04828;
	Tue, 2 Jan 2001 10:03:33 -0800 (PST)
Received: from sony-laptop (rmahy-dsl5.cisco.com [10.19.53.126])
	by imop.cisco.com (Mirapoint)
	with SMTP id AAF93065;
	Tue, 2 Jan 2001 10:03:10 -0800 (PST)
Message-Id: <4.1.20010102094413.00cb77d0@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
To: "Ben Campbell" <bcampbell@dynamicsoft.com>,
        "'Billy Biggs'" <billy@billybiggs.com>,
        "Ben Campbell" <bcampbell@dynamicsoft.com>
From: Rohan Mahy <rohan@cisco.com>
Subject: RE: [SIP] Solving the REFER retransmit issue
Cc: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>,
        "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
        "Robert Sparks" <rsparks@dynamicsoft.com>,
        "SIP List" <sip@lists.bell-labs.com>,
        "Sean Olson" <sean.olson@ericsson.com>
In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3B573@DYN-TX-EXCH-001.dynam
 icsoft.com>
References: <20001229153044.A311@div8.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 02 Jan 2001 10:06:47 -0800

At 01:54 PM 12/29/00 , Ben Campbell wrote:
>> From: Billy Biggs [mailto:billy@billybiggs.com]
>> Sent: Friday, December 29, 2000 3:31 PM
>> To: Ben Campbell
>> Cc: Jonathan Rosenberg; Henning G. Schulzrinne; Rohan Mahy; Robert
>> Sparks; SIP List; Sean Olson
>> Subject: Re: [SIP] Solving the REFER retransmit issue
>>
>>
>> Ben Campbell (bcampbell@dynamicsoft.com):
>>
>> > I realize this creates additional message overhead in the case where
>> > the REFER-or cares about the results. However, if present day PSTN
>> > stuff is an example, I fully expect the vast majority of REFER
>> > applications to _not_ care about the results (e.g. blind transfer or
>> > similar). In this case, the implied subscription actually creates
>> > additional message overhead. [...]
>>
>>   Attended transfer (call handoff) is the primitve necessary for most
>> advanced phone services.  Say B is in a 3-way call:
>
>I do not suggest that attended transfer is unimportant, merely that blind
>transfers will probably happen more often in the SIP world at large. 

I disagree.  Attended transfer is used much more often than you imply in
the PBX and PSTN worlds, and with the built-in redirection without
answering, and forking funtionality of SIP, many more current uses of blind
transfer can be avoided.  remember that the problem blind transfer was
trying to solve was to get rid of the call.  REFER with implicit NOTIFY
(and Billy's proposal for that matter) gets rid of the call, and you can
blissfully ignore any NOTIFYs you get.

>While
>attended transfer is a primitive of advanced services, blind transfer is an
>extremely commonly used _simple_ service. I prefer to optimize for the
>simple case, and make the advanced case do a bit more work than the other
>way around. The timing expectations for an attended transfer may be tight,
>but they are even tighter for an unattended transfer.

hogwash.  the timing expectations are identical.  attended transfer is
*HARDLY* an advanced case.   For example: screening your incoming voicemail
is a more advanced feature which uses more than one primitive working
together.  if we cripple our primitives now, we will have call flows worthy
of H.323v1, huge message counts, and the services everyone keeps promising
will not appear.  (I counted over 100 messages for a fairly straightforward
call screening example with the REFER, SUB, NTFY method).  God forbid if we
add manyfolks QoS to any of these flows, or security....

fundamentally we need to initiate, terminate, move, join, split, and get
status of call-legs.  THESE are the types of primitives we need.  An
inherent part of moving call legs is being able to find out what happened;
it is not optional.

thanks,
-rohan


>
>>
>>                        A       C
>>                          \   /
>>                            B
>>
>>   B needs to know when A has successfully contacted C so it can
>> terminate its calls.
>>
>>   In any reasonable phone system, the handoff has to be close to
>> instantaneous.  This is at odds with suggestions that:
>>
>>  - B SUBSCRIBE'ing to A before getting back a response.
>>  - A sending a NOTIFY before a re-INVITE or BYE.
>>  - ...
>>
>>   Please, consider implementation pain and message verbosity.
>>
>
>I did not see any proposal that said B _must_ wait for the notify to send a
>BYE. I suspect that would be a common implementation, but B _could_ send a
>bye immediately, then if it later received a NOTIFY indicating failure, it
>could notify the user, invite A to a new call, or whatever behavior makes
>the most sense in the situation.
>
>


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 13:08:00 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20734
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 13:08:00 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E8D1B44353; Tue,  2 Jan 2001 12:08:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id 3803144343
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 12:07:20 -0500 (EST)
Received: (qmail 31905 invoked by uid 500); 2 Jan 2001 18:49:46 -0000
From: David Frascone <dave@frascone.com>
To: "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
Subject: Re: [SIP] Discussion of Default Timers
Message-ID: <20010102124945.B31857@newman.frascone.com>
Mail-Followup-To: "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
References: <00b801c074e1$1946d530$ea036e3f@dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <00b801c074e1$1946d530$ea036e3f@dynamicsoft.com>; from dean.willis@softarmor.com on Tue, Jan 02, 2001 at 11:26:09AM -0600
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 12:49:46 -0600

Hmmm, I think your router lag is a bit off.  Doing a ping from Dallas, TX to
somewhere in China (www.hackersquest.gomp.ch) yeilds ~160ms round trip time.

And, I'm 24 hops from there.  24 * 10ms would be 240 ms of router lag alone.

So, I think your calculations are a bit off.

On Tue, Jan 02, 2001 at 11:26:09AM -0600, Dean Willis wrote:
> 
> I've started to wonder about the retransmission timers recommended in 2543.
> 
> The basic assumption is that VoIP networks will have round-trip times of
> less than 500ms. This seems to be a valid assumptio for the medai path, but
> remember -- with SIP, the SIGNALING path is not necessarily thesame as the
> MEDIA path. And the timers apply to the SIGNALING path.
> 
> Many of the architectures I'm seeing have three thousand kilometers, ten
> routers, and six proxies between two SIP endpoints.  Assuming 6ms/1000km,
> 10ms/router, and 50ms/proxy, that works out to 418ms each way, or a total of
> 836ms round trip. With default settings, the originating UA is going to
> resend its INVITE after only 500ms unless response is received. Everybody
> wants to use stateless proxies for performance reaons. So, nearly every
> INVITE gets sent twice. This can be severely detrimental to the function of
> a proxy that is operating at near peak capacity -- in fact, it basically
> cuts the peak capacity of a proxy in half whenever proxy chains are
> configured in such a way that T1 is regularly exceeded.
> 
> There are a couple of alternatives that come to mind:
> 
> 1) Deploy faster proxies.
> 2) Deploy 100-generating proxies at all levels to prevent timer expiration
> due to downstream latency.
> 3) Change the default timers.
> 
> Thoughts?
> 
> --
> Dean Willis
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 13:33:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20978
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 13:33:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 478854433B; Tue,  2 Jan 2001 12:34:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from host-1.ttimail.com (host-1.ttimail.com [216.86.19.6])
	by lists.bell-labs.com (Postfix) with ESMTP id 3FFFB44337
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 12:33:36 -0500 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [SIP] Discussion of Default Timers
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Message-ID: <766C3CB30588BB48B34C55C2BEDF500324A2D1@host-1.ttiworld.com>
Thread-Topic: [SIP] Discussion of Default Timers
Thread-Index: AcB05Qp3pcNCEns4Qe6F42SrWesg3AABL4pw
From: "Kevin Summers" <Kevin.Summers@ttimail.com>
To: "Sean Olson" <sean.olson@ericsson.com>,
        "Dean Willis" <dean.willis@softarmor.com>
Cc: "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 12:30:18 -0600
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA20978

With regards to (3), this timer really should be configurable (our
implementation allows it to be). A pretty important attribute to be able
to control, in my mind.

Kevin

-----Original Message-----
From: Sean Olson [mailto:sean.olson@ericsson.com]
Sent: Tuesday, January 02, 2001 11:55 AM
To: Dean Willis
Cc: IETF SIP (E-mail)
Subject: Re: [SIP] Discussion of Default Timers


I agree that this is a problem and it is aggravated in the
case of wireless access where latencies are even larger.

Regarding the alternatives you list:

1) Faster proxies -- this is basically chasing rainbows. The processing
   delay can only be cut down so much and it is prone to break when
   new topologies introduce additional proxies

2) More statefull proxies -- This seems like a reasonable approach
   for many deployments (enterprise and GSTN gateways in particular)
   but of course can't be fixed by standardization, i.e. we can't
   mandate this (at least in the SIP spec)

3) Changing the default timers -- I like this approach but I think
   it isn't realistic given the current implementations. How many
   implementations hard-code this value I wonder?

I would recommend a combination of alternatives 2 and 3 for 
most architectures. Perhaps this could be part of a larger set
of recommendations in a BCP?

/sean

Dean Willis wrote:
> 
> I've started to wonder about the retransmission timers recommended in
2543.
> 
> The basic assumption is that VoIP networks will have round-trip times
of
> less than 500ms. This seems to be a valid assumptio for the medai
path, but
> remember -- with SIP, the SIGNALING path is not necessarily thesame as
the
> MEDIA path. And the timers apply to the SIGNALING path.
> 
> Many of the architectures I'm seeing have three thousand kilometers,
ten
> routers, and six proxies between two SIP endpoints.  Assuming
6ms/1000km,
> 10ms/router, and 50ms/proxy, that works out to 418ms each way, or a
total of
> 836ms round trip. With default settings, the originating UA is going
to
> resend its INVITE after only 500ms unless response is received.
Everybody
> wants to use stateless proxies for performance reaons. So, nearly
every
> INVITE gets sent twice. This can be severely detrimental to the
function of
> a proxy that is operating at near peak capacity -- in fact, it
basically
> cuts the peak capacity of a proxy in half whenever proxy chains are
> configured in such a way that T1 is regularly exceeded.
> 
> There are a couple of alternatives that come to mind:
> 
> 1) Deploy faster proxies.
> 2) Deploy 100-generating proxies at all levels to prevent timer
expiration
> due to downstream latency.
> 3) Change the default timers.
> 
> Thoughts?
> 
> --
> Dean Willis
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 13:39:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21107
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 13:39:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7D6D344346; Tue,  2 Jan 2001 12:40:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id F3AB144343
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 12:39:03 -0500 (EST)
Received: from cowboys (IDENT:root@localhost [127.0.0.1])
	by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id AAA17014;
	Wed, 3 Jan 2001 00:44:51 -0600
Message-ID: <00d801c074ea$db87e720$ea036e3f@dynamicsoft.com>
From: "Dean Willis" <dean.willis@softarmor.com>
To: "David Frascone" <dave@frascone.com>,
        "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
References: <00b801c074e1$1946d530$ea036e3f@dynamicsoft.com> <20010102124945.B31857@newman.frascone.com>
Subject: Re: [SIP] Discussion of Default Timers
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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 12:36:01 -0600
Content-Transfer-Encoding: 7bit


Well, those are the rough rules of thumb we used in network design just a
few years ago. Routers often perform much better these days -- assuming you
don't hit head of line blocking, small pipe serialization delay, an OSPF MST
recalc, a sluggish store-and-forward firewall,  congested MAE, or some other
annoyance  en-route. 10ms per router does represent a useful outer bound for
planning purposes. 3ms is probably closer to mean.

And the particular destination you listed www.hackersquest.gomp.ch is
hanging right off the uunet backbone -- 180 ms from my uunet-connected
router. There are worse routes.

But in any case, I have seen trial deployments where large numbers of T1
expirations occur.

Even if network transit time is only 180ms, a couple of proxies in between
can still easily push us over 500ms.

--
Dean

----- Original Message -----
From: "David Frascone" <dave@frascone.com>
To: "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
Sent: Tuesday, January 02, 2001 12:49 PM
Subject: Re: [SIP] Discussion of Default Timers


> Hmmm, I think your router lag is a bit off.  Doing a ping from Dallas, TX
to
> somewhere in China (www.hackersquest.gomp.ch) yeilds ~160ms round trip
time.
>
> And, I'm 24 hops from there.  24 * 10ms would be 240 ms of router lag
alone.
>
> So, I think your calculations are a bit off.
>
> On Tue, Jan 02, 2001 at 11:26:09AM -0600, Dean Willis wrote:
> >
> > I've started to wonder about the retransmission timers recommended in
2543.
> >
> > The basic assumption is that VoIP networks will have round-trip times of
> > less than 500ms. This seems to be a valid assumptio for the medai path,
but
> > remember -- with SIP, the SIGNALING path is not necessarily thesame as
the
> > MEDIA path. And the timers apply to the SIGNALING path.
> >
> > Many of the architectures I'm seeing have three thousand kilometers, ten
> > routers, and six proxies between two SIP endpoints.  Assuming
6ms/1000km,
> > 10ms/router, and 50ms/proxy, that works out to 418ms each way, or a
total of
> > 836ms round trip. With default settings, the originating UA is going to
> > resend its INVITE after only 500ms unless response is received.
Everybody
> > wants to use stateless proxies for performance reaons. So, nearly every
> > INVITE gets sent twice. This can be severely detrimental to the function
of
> > a proxy that is operating at near peak capacity -- in fact, it basically
> > cuts the peak capacity of a proxy in half whenever proxy chains are
> > configured in such a way that T1 is regularly exceeded.
> >
> > There are a couple of alternatives that come to mind:
> >
> > 1) Deploy faster proxies.
> > 2) Deploy 100-generating proxies at all levels to prevent timer
expiration
> > due to downstream latency.
> > 3) Change the default timers.
> >
> > Thoughts?
> >
> > --
> > Dean Willis
> >
> >
> >
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 13:52:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21343
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 13:52:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5D95044353; Tue,  2 Jan 2001 12:53:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by lists.bell-labs.com (Postfix) with ESMTP id CFD014434F
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 12:52:57 -0500 (EST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 2 Jan 2001 10:45:56 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Jan 2001 10:46:39 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532);
	 Tue, 2 Jan 2001 10:46:39 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0
content-class: urn:content-classes:message
Subject: RE: [SIP] new record-route text!
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Message-ID: <CC2E64D4B3BAB646A87B5A3AE97090420EFB3EF3@speak.dogfood>
Thread-Topic: [SIP] new record-route text!
Thread-Index: AcByWVjBwh0XrXBSSwuzyZDn3GkfdQCkhrcw
From: "Christian Huitema" <huitema@exchange.microsoft.com>
To: "Henning Schulzrinne" <hgs@cs.columbia.edu>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: <sip@lists.bell-labs.com>
X-OriginalArrivalTime: 02 Jan 2001 18:46:39.0833 (UTC) FILETIME=[57AB6C90:01C074EC]
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 10:46:37 -0800
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA21343

I am concerned with the mandatory aspect of the record-route parameter.
Part of the beauty of SIP is that it can operate in a strict end-to-end
mode; the record-route procedure allows intermediaries to arbitrarily
break that end-to-end property. I understand that this could be useful
sometimes, for some crazy network configurations, but if we make this
mandatory we should have at a minimum an escape hatch. More precisely,
the syntax of the contact header should allow us to distinguish between
two cases:
1) a contact address that can only be reached through the recorded
route,
2) a contact address that can be accessed directly.
I would contend that, if we don't want to recycle the SIP spec to the
proposed standard spec, the latter should be the default, as the strict
record route requirement breaks compatibility with the original
specification.

-- Christian Huitema

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 14:32:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21941
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 14:32:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9AE994433B; Tue,  2 Jan 2001 13:33:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail15b.boca15-verio.com (unknown [208.55.91.59])
	by lists.bell-labs.com (Postfix) with SMTP id 0A35944337
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 13:32:05 -0500 (EST)
Received: from 128.241.144.247 (128.241.144.247)
	by mail15b.boca15-verio.com (RS ver 1.0.58s) with SMTP id c13817129;
	Tue,  2 Jan 2001 14:31:34 -0500 (EST)
From: "Eric Burger" <eburger@snowshore.com>
To: "Ashhar Farhan" <afarhan@rediffmail.com>, <sip@lists.bell-labs.com>
Subject: RE: [SIP] a tiny binary sip proxy protocol
Message-ID: <NEBBLACLCLHMJBCAJGOEIELFCGAA.eburger@snowshore.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <20001230081322.14756.qmail@mailweb7.rediffmail.com>
X-Loop-Detect: 1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 14:31:44 -0500
Content-Transfer-Encoding: 7bit

The idea of a "SIP Lite" sounds interesting.  However, what benefit do you
see by having the protocol binary?  With shorts and ints, you run into
network byte-order problems.

What precisely does the proposal try to fix?  Items 3 and 4 could be useful;
does anyone else on the list have an opinion

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Ashhar Farhan
> Sent: Saturday, December 30, 2000 3:13 AM
> To: sip@lists.bell-labs.com.
> Subject: [SIP] a tiny binary sip proxy protocol
>
>
> i am proposing a very easily implemented, binary level protocol
> that can easily translate to and from sip
> signalling. the protocol is right now called STP (Sip's Tiny Proxy).
> the protocol has the following features:
>
> 1. it can painlessly traverse SOCKS 5 proxies, NAT and other
> forms of proxy like WinSock. It uses in-band signalling so that a
> single port on proxies and firewalls is used for both streaming
> as well as signalling. This is an issue of immense importance
> currently. Most of the people who have an always on presence on
> the Net are usually behind a proxy of some sort.
>
> 2. the signalling uses binary structures that can be directly
> read into C structures eliminating the need of costly parsers.
> This leads to a loss of many facilities inherent in SIP. This is
> by design. It is a cut down protocol that can easily translate to
> SIP through a gateway.
>
> 3. All the signalling messages are handled uniformly (retransmit
> until response or time-out). forking is not allowed. INVITE and
> ACK are replaced with RING and ANSWER (as two separate messages).
>
> 4. No call parameter renegotiation is allowed.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 14:33:47 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21965
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 14:33:47 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E14284434C; Tue,  2 Jan 2001 13:33:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail15b.boca15-verio.com (unknown [208.55.91.59])
	by lists.bell-labs.com (Postfix) with SMTP id 83BE744337
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 13:32:10 -0500 (EST)
Received: from 128.241.144.247 (128.241.144.247)
	by mail15b.boca15-verio.com (RS ver 1.0.58s) with SMTP id d13817129;
	Tue,  2 Jan 2001 14:31:42 -0500 (EST)
From: "Eric Burger" <eburger@snowshore.com>
To: <Javier_Ferreiro_Garcia/UT03329/PLATAFORMAS_DE_SERVICIOS/TSM@tsm.es>
Cc: <sip@lists.bell-labs.com>
Subject: RE: [SIP] 3PCC and REFER method
Message-ID: <NEBBLACLCLHMJBCAJGOEKELFCGAA.eburger@snowshore.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <OF398DAAD8.B83699EF-ONC12569C4.0033E09F@tsm.es>
X-Loop-Detect: 1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 14:31:49 -0500
Content-Transfer-Encoding: 7bit

I'd worry about a third-party directing an end-point to establish a call.
In particular, there are interesting billing issues (although one could say
this solves a billing issue).  For example, if the HTTP server sends the "Go
call the controller" message to Terminal A, the network sees a call
origination from Terminal A.  That may, or may not, be the intention of the
service provider.

What precisely is the issue with having the controller issuing the INVITEs
to A and B?

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of
> Javier_Ferreiro_Garcia/UT03329/PLATAFORMAS_DE_SERVICIOS/TSM@tsm.es
> Sent: Friday, December 29, 2000 6:00 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] 3PCC and REFER method
>
>
> Hi
> I would like to open again the issue discussed in
> http://lists.bell-labs.com/pipermail/sip/2000q4/004739.html
>
> >>What happens when there is not an active SIP (INVITE) session
> between the
> >>referer and referee ? Sending an INVITE in this case may have unwanted
> >>effects (like initiating a call). Are you proposing that either a) you
> would
> >>only send the INVITE/BYE if a corresponding SIP (INVITE) sessions exists
> or
> >>b) that REFERS are not allowed outside of a SIP session?
>
> >  What does a REFER outside of a session mean?
>
> and apply this idea to the scenario proposed in
> draft-rosenberg-sip-3pcc-01.txt Figure 1 and specifically the
> example included for Click-to-dial application.
>
> In this alternative scenario for Click-to-dial, the controller, after
> receiving the request via HTTP, do not INVITE both A and B, but
> rather send
> a REFER to A, asking A to INVITE the CONTROLER ITSELF. When the controller
> receives the INVITE SDP A from A, checks in its internal database who is
> supposed to be contacted by A (in this case B) and sends INVITE
> SDP A to B.
> In this case I think the re-INVITE loop could be avoided by  applying this
> scenario which is more similar to a normal INVITE between two parties.
>
> In this alternative scenario the referer (i.e. the controller) and the
> referee (i.e. the web-surfer) are OUTSIDE of a SIP session, but INSIDE an
> HTTP session. It could also be decided the referee to be the IP phone from
> the customer service representative, if the web-surfer IP phone
> either does
> not support REFER or is a PSTN endpoint.
>
> The reason to include as content of Refer-To header not B but the
> controller itself is to let the controller do its job in a more
> general way
> (i.e. imagine click-to-dial + mid-call-announcement)
>
> If the scenario is not the one described for Click-to-dial, but for Mid
> Call AnnouncementCapability, the controller does not either set
> up the call
> to A or send the REFER method to A, but rather receive the INVITE from A
> and act as a "termination and reinitiation point" for control purposes
> (i.e. disconnect and reconnect A to a media server under certain
> conditions) as defined in draft-rosenberg-sip-3pcc-01.txt
[snip]


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 16:16:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22785
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 16:16:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C96B24433A; Tue,  2 Jan 2001 15:17:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from june.Broomfield1.level3.net (unknown [209.245.18.7])
	by lists.bell-labs.com (Postfix) with ESMTP id 657B744337
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 15:16:29 -0500 (EST)
Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204])
	by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id VAA23446;
	Tue, 2 Jan 2001 21:14:56 GMT
From: Jon.Peterson@Level3.com
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id VAA00811;
	Tue, 2 Jan 2001 21:14:56 GMT
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id <CFJHHJ8V>; Tue, 2 Jan 2001 14:16:59 -0700
Message-ID: <6384220893BCD411BDFE0008C791B79C232CA5@N0228IDC1.oss.level3.com>
To: dean.willis@softarmor.com, sip@lists.bell-labs.com
Subject: RE: [SIP] Discussion of Default Timers
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 14:13:21 -0700


I would imagine that 'six proxy' architectures will eventually fall by the
wayside. Today, even, I'd imagine that for most networks, the majority of
those six proxies are either ALGs controlling FWs or stateless proxies that
are thrown in to achieve greater scalability or availability.

Whether or not we will always consider a SIP ALG to be a proxy, I doubt that
the ALG function will be going away anytime soon - ALGs will always be a
source of latency as long as the FW/NAT function is considered useful at the
edges of a VoIP network (though the ALG cost will not be realized in
intradomain gateway-to-gateway calls, for example). Stateless proxies used
for load sharing or fault tolerance, however, will go away, I think; they'll
be replaced by hardware load-balancers, or what have you, that will provide
scale and availability at near-router costs in latency. So, I suppose from
my perspective it is realistic to adopt the 'deploy fewer proxies'
philosophy in the long term.

In the short term, a full second or more of post-dial delay is not uncommon
for international calls in the PSTN today. We are talking about signaling
latency, not media latency. Media latency is widely reputed to be audible
and annoying after around 250ms. Signaling latency becomes problematic only
when the cross office max is so vast that the user becomes frustrated, hangs
up and tries the call again, which generally won't happen until some serious
time has passed. That much said, I do think SIP's timers are reasonable
sized, considering that the cost of not re-transmitting when a packet has
been lost to a recoverable network error is, of course, increased post-dial
delay (for that admittedly small percentage of calls). So I suppose I like
the '100' option as a short-term solution. Sending 100 is generally a
configurable option on proxies in my experience. It generates some
additional busywork for the network, but certainly less so than reprocessing
INVITEs.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: Tuesday, January 02, 2001 10:26 AM
To: IETF SIP (E-mail)
Subject: [SIP] Discussion of Default Timers



I've started to wonder about the retransmission timers recommended in 2543.

The basic assumption is that VoIP networks will have round-trip times of
less than 500ms. This seems to be a valid assumptio for the medai path, but
remember -- with SIP, the SIGNALING path is not necessarily thesame as the
MEDIA path. And the timers apply to the SIGNALING path.

Many of the architectures I'm seeing have three thousand kilometers, ten
routers, and six proxies between two SIP endpoints.  Assuming 6ms/1000km,
10ms/router, and 50ms/proxy, that works out to 418ms each way, or a total of
836ms round trip. With default settings, the originating UA is going to
resend its INVITE after only 500ms unless response is received. Everybody
wants to use stateless proxies for performance reaons. So, nearly every
INVITE gets sent twice. This can be severely detrimental to the function of
a proxy that is operating at near peak capacity -- in fact, it basically
cuts the peak capacity of a proxy in half whenever proxy chains are
configured in such a way that T1 is regularly exceeded.

There are a couple of alternatives that come to mind:

1) Deploy faster proxies.
2) Deploy 100-generating proxies at all levels to prevent timer expiration
due to downstream latency.
3) Change the default timers.

Thoughts?

--
Dean Willis




_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 16:23:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22841
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 16:23:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 229564433A; Tue,  2 Jan 2001 15:24:02 -0500 (EST)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id ECF5E44337
	for <sip@share.research.bell-labs.com>; Tue,  2 Jan 2001 15:23:25 -0500 (EST)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jan  2 16:20:21 EST 2001
Received: by lists.bell-labs.com (Postfix)
	id 9AEF144380; Tue,  2 Jan 2001 16:08:23 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5])
	by lists.bell-labs.com (Postfix) with SMTP id 4B6224437D
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 16:08:23 -0500 (EST)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id PAA02527; Tue, 2 Jan 2001 15:08:19 -0600
Cc: SIP LIST <sip@lists.bell-labs.com>
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id PAA02515; Tue, 2 Jan 2001 15:08:16 -0600
Message-ID: <3A52433A.AAADD54@lucent.com>
From: Vijay Gurbani <vkg@lucent.com>
Organization: Lucent Technologies
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Original-CC: SIP LIST <sip@lists.bell-labs.com>
Subject: Re: [SIP] new record-route text!
References: <B65B4F8437968F488A01A940B21982BF9AAF4D@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 02 Jan 2001 15:08:10 -0600
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> Folks,
> 
> I took a stab at the new text for record routing. Its much, much more
> verbose than rfc2543, and hopefully, as a result, will make it much 
> clearer what you need to do.
[...]
> Please comment; alternate text related to those comments is requested.

Jonathan:

The text uses R-R parameters to implement certain functionality.  R-R param-
eters are specified in the bis BNF for Record-Route; RFC 2543 BNF did not 
contain R-R parameters for Record-Route.  What happens if a R-R with 
parameters inserted by a proxy makes its way to a RFC 2543 UAS, which does 
not echo R-R parameters in the 2xx response (since it does not know how to 
parse them)?  In this case, the proxy may not be able to correlate the 
response to the apppropriate R-R for header modification.

Assuming we are dealing with all bis implemented SIP entities, then the 
example you provide would (to me, anyway) make more sense if the 
myparam=9877 was appended by the proxy at 10.0.1.1 to the INVITE going 
downstream instead of the 2xx going upstream, especially given the para-
graphs that follow.

> OPEN-ISSUE: Handling for non-200 responses, including provisionals
> and certain 400 class responses. Are we supporting record-routing for
> non-200 class responses? Record-routing for provisional responses is
> discussed in the 100rel spec. What needs to be said here?

I would think R-R makes sense for 2xx responses only.

> OPEN-ISSUE: should the UA remove the maddr param, if present, if the
> request is sent to the server at that maddr?

I would say probably not; no good reason for it, though.  I don't think it
hinders any.

Henning mentioned some verbiage about handling record-routing of non-INVITE
requests, which I think should be added as well.

Thanks for the time to document this...

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 16:27:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22875
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 16:27:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AA6164433A; Tue,  2 Jan 2001 15:28:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7])
	by lists.bell-labs.com (Postfix) with ESMTP id 7042444337
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 15:27:29 -0500 (EST)
Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204])
	by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id VAA29115;
	Tue, 2 Jan 2001 21:27:17 GMT
From: Jon.Peterson@Level3.com
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id VAA02405;
	Tue, 2 Jan 2001 21:27:16 GMT
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id <CFJHHKJA>; Tue, 2 Jan 2001 14:29:19 -0700
Message-ID: <6384220893BCD411BDFE0008C791B79C232CA6@N0228IDC1.oss.level3.com>
To: huitema@exchange.microsoft.com, hgs@cs.columbia.edu,
        jdrosen@dynamicsoft.com
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] new record-route text!
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 14:25:45 -0700

This would just encourage the use of B2BUAs by service providers who want to
retain control over the call (for applications, for billing, or other insane
and nefarious purposes). Nothing can prevent the administration of a proxy
in the chain of signaling (a chain ultimately initiated by the user) from
forcing all subsequent requests for a call to go through its systems - that
is their architectural perogative. B2BUAs may, however, break some
end-to-end mechanisms and introduce further latency to the signaling.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Christian Huitema [mailto:huitema@exchange.microsoft.com]
Sent: Tuesday, January 02, 2001 11:47 AM
To: Henning Schulzrinne; Jonathan Rosenberg
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] new record-route text!


I am concerned with the mandatory aspect of the record-route parameter.
Part of the beauty of SIP is that it can operate in a strict end-to-end
mode; the record-route procedure allows intermediaries to arbitrarily
break that end-to-end property. I understand that this could be useful
sometimes, for some crazy network configurations, but if we make this
mandatory we should have at a minimum an escape hatch. More precisely,
the syntax of the contact header should allow us to distinguish between
two cases:
1) a contact address that can only be reached through the recorded
route,
2) a contact address that can be accessed directly.
I would contend that, if we don't want to recycle the SIP spec to the
proposed standard spec, the latter should be the default, as the strict
record route requirement breaks compatibility with the original
specification.

-- Christian Huitema

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 17:23:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23376
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 17:23:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 46D4344338; Tue,  2 Jan 2001 16:24:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id A1FB544337
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 16:23:06 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05540
	for <sip@lists.bell-labs.com>; Tue, 2 Jan 2001 14:22:55 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA13566
	for <sip@lists.bell-labs.com>; Tue, 2 Jan 2001 14:22:54 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA12822
	for <sip@lists.bell-labs.com>; Tue, 2 Jan 2001 14:22:53 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
To: SIP List <sip@lists.bell-labs.com>
In-Reply-To: "Your message with ID" <20001231132059.C24183@newman.frascone.com>
Message-ID: <Roam.SIMC.2.0.6.978473964.32701.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 14:19:24 -0800 (PST)

> The document has not been discussed in the AAA
> WG, because AAA is focused on network access
> requirements. 

Correct. For the record, however, the AAA did at one point consider SIP (or
VoIP). At that time, the WG requested requirements for this application, but
they weren't forthcoming :( Since only requirements for network access were
received, the WG re-chartered to focus on the problems that were defined. This
new focus has allows the WG to move much more efficiently.

Given the above, the AAA WG still should not diverge from its current path.
Any other WG that requires AAA should first come up with their requirements,
then perhaps see if the AAA protocol can satisfy those requirements.

> 
> Thus, it is completely up to the SIP WG to
> define the security requirements for SIP,
> which may or may not require AAA functionality
> as a solution.

Correct. The 3G folks have roaming requirements, which led them to AAA. 

> 
> I'd note that for applications such as
> telephony, where the client can often be
> presumed to have Internet access, a wider
> range of security solutions are available
> than in network access, where by definition
> the client does not have network access 
> prior to authentication. 

Whether of not the client has access to the 'net or not, I believe that a set
of requirements needs to be spelled out. We have attempted to do so in our
document, with an assumption that AAA will be used to exchange authorization
information in roaming situations.


PatC


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 17:35:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23501
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 17:35:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 057994433F; Tue,  2 Jan 2001 16:36:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 9BDA444338
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 16:35:03 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA07386
	for <sip@lists.bell-labs.com>; Tue, 2 Jan 2001 14:34:48 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA16505
	for <sip@lists.bell-labs.com>; Tue, 2 Jan 2001 14:34:47 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA13159
	for <sip@lists.bell-labs.com>; Tue, 2 Jan 2001 14:34:46 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: Re: [Henry.Sinnreich@wcom.com: RE: [SIP] draft-calhoun-sip-aaa-req]
To: SIP List <sip@lists.bell-labs.com>
In-Reply-To: "Your message with ID" <20001231132122.D24183@newman.frascone.com>
Message-ID: <Roam.SIMC.2.0.6.978474677.24565.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 14:31:17 -0800 (PST)

> >The document has not been discussed in the AAA
> >WG, because AAA is focused on network access
> >requirements.
> 
> Thanks for the clarification! 

Just to make sure that you understand Bernard's clarification, his statement
is that the AAA WG is only focused on network access. The AAA WG is not
concerned with any other WG that may, or may not, wish to make use of AAA. I
believe that SIP is one WG that does require AAA-like services.

> Have felt very uncomfortable with Diameter for
> applications in the <always connected> case for various reasons, not at
> least because of the AVP data format (prefer XML).

We've had this discussion in the past, and I guess we'll have it here as well.
As I understand it, you would like XML to be used in the accounting messages
so users can "view" their accounting records through some standard browser. I
state accounting here because I don't see why users would need to see the
authentication messages on their browsers.

The above, btw, has nothing to do with whether a protocol uses AVPs, TLVs, or
anything else. The fact of the matter is that some XML data needs to be
transported from a SIP server to accounting server. Why would user's using
their browsers care how the accounting records make it from the network
servers? Unless one wishes to use browsers to "sniff" the packets on the
network, it doesn't matter (and the fact that the layers below AAA aren't XML
would cause this to break anyways).

So one can do one of the following:
1. have accounting servers generate XML from accounting information
2. have SIP servers include XML accounting record, embedded within the
protocol, or 3. use an XML-only protocol (and redo lots of roaming and
security work)

Lastly, do users wish to view individual accounting records, with each call
being a separate XML document, or rather a compiled list of network events? As
a user, I really like having a compiled list for me. It seems much simpler
than having to comb through countless documents to get the info I need.

PatC


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 17:45:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23653
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 17:45:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DE5A74434E; Tue,  2 Jan 2001 16:46:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id 1AEC04433C
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 16:45:16 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17684;
	Tue, 2 Jan 2001 14:44:53 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA19027;
	Tue, 2 Jan 2001 14:44:53 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA13429;
	Tue, 2 Jan 2001 14:44:51 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
To: Michael Thomas <mat@cisco.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, SIP List <sip@lists.bell-labs.com>
In-Reply-To: "Your message with ID" <14930.22653.542206.833943@thomasm-u1.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.978475283.27352.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 14:41:23 -0800 (PST)

>    I don't understand what roaming, per se, has to do
>    with SIP. How is that any different than just
>    REGISTER'ing to a new SIP registrar? I have
>    seen people want to reuse their RADIUS
>    infrastructure since it's sort of used as a
>    catch all user database, but that too seems
>    orthogonal to roaming and SIP.
and
>    That's _one_ way to do it, I suppose. It seems
>    a lot more natural to do direct authentication
>    of the SIP traffic on whatever device
>    (including UAS's) is the target of the SIP
>    message and perhaps use an LDAP or XML based
>    backend to transport the database goodies. 
> 

Devices can request services in foreign networks. Now perhaps
you are willing to open up your LDAP database to the outside world,
but the 3G folks aren't.


>    The only reason I can see to shoe horn it into
>    RADIUS/DIAMETER is because of legacy database
>    considerations, but that's only one set of
>    SIP installations which will have that as a
>    large consideration.

The 3G folks are forcasting billions of devices in the next few years,
and require such a backend. However as you state the document does in fact
attempt to solve a specific problem set. It is possible that corporate networks
have different requirements, hence multiple backends (AAA, LDAP, etc.)

PatC


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 17:49:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23694
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 17:49:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 77E4E44353; Tue,  2 Jan 2001 16:50:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 3C40D4434E
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 16:49:46 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA12707;
	Tue, 2 Jan 2001 17:49:18 -0500 (EST)
Message-ID: <3A525AEF.1DCDF526@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: Michael Thomas <mat@cisco.com>, SIP List <sip@lists.bell-labs.com>
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
References: <Roam.SIMC.2.0.6.978475283.27352.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 02 Jan 2001 17:49:19 -0500
Content-Transfer-Encoding: 7bit

Pat Calhoun wrote:
> 
> >    I don't understand what roaming, per se, has to do
> >    with SIP. How is that any different than just
> >    REGISTER'ing to a new SIP registrar? I have
> >    seen people want to reuse their RADIUS
> >    infrastructure since it's sort of used as a
> >    catch all user database, but that too seems
> >    orthogonal to roaming and SIP.
> and
> >    That's _one_ way to do it, I suppose. It seems
> >    a lot more natural to do direct authentication
> >    of the SIP traffic on whatever device
> >    (including UAS's) is the target of the SIP
> >    message and perhaps use an LDAP or XML based
> >    backend to transport the database goodies.
> >
> 
> Devices can request services in foreign networks. Now perhaps
> you are willing to open up your LDAP database to the outside world,
> but the 3G folks aren't.
> 
> >    The only reason I can see to shoe horn it into
> >    RADIUS/DIAMETER is because of legacy database
> >    considerations, but that's only one set of
> >    SIP installations which will have that as a
> >    large consideration.
> 
> The 3G folks are forcasting billions of devices in the next few years,
> and require such a backend. However as you state the document does in fact
> attempt to solve a specific problem set. It is possible that corporate networks
> have different requirements, hence multiple backends (AAA, LDAP, etc.)
> 

I'm still trying to understand why the act of sending SIP requests is
subject to authorization. Will each new UDP port number and service get
its own AAA infrastructure? (I can see authorizing resource
reservations, but that's completely orthogonal to SIP, as has been
discussed here a few times...)


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 17:57:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23801
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 17:57:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3C6134433E; Tue,  2 Jan 2001 16:58:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 5479144338
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 16:57:45 -0500 (EST)
Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id WAA00982
	for <sip@lists.bell-labs.com>; Tue, 2 Jan 2001 22:58:55 GMT
Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 02 Jan 2001 22:57:31 0000 (GMT)
Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <ZNDYRZBX>; Tue, 2 Jan 2001 14:57:30 -0800
Message-ID: <4148FEAAD879D311AC5700A0C969E8902D4905@orsmsx35.jf.intel.com>
From: "Gross, Gerhard" <gerhard.gross@intel.com>
To: sip@lists.bell-labs.com
Subject: RE: [SIP] Discussion of Default Timers
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 14:56:15 -0800

Another possible source of signaling latency
can come from policy management and AAA.
During call setup, one or more policy/AAA servers
may need to be accessed for policy decisions,
authentication tokens, etc. Most policy decisions
will likely be handled intra-domain, only adding
a small amount of latency. Inter-domain signaling,
such as that which may be needed for AAA (clearing-
house access) is probably not negligible.

Gery

> -----Original Message-----
> From: Jon.Peterson@Level3.com [mailto:Jon.Peterson@Level3.com]
> Sent: Tuesday, January 02, 2001 1:13 PM
> To: dean.willis@softarmor.com; sip@lists.bell-labs.com
> Subject: RE: [SIP] Discussion of Default Timers
> 
> 
> 
> I would imagine that 'six proxy' architectures will 
> eventually fall by the
> wayside. Today, even, I'd imagine that for most networks, the 
> majority of
> those six proxies are either ALGs controlling FWs or 
> stateless proxies that
> are thrown in to achieve greater scalability or availability.
> 
> Whether or not we will always consider a SIP ALG to be a 
> proxy, I doubt that
> the ALG function will be going away anytime soon - ALGs will 
> always be a
> source of latency as long as the FW/NAT function is 
> considered useful at the
> edges of a VoIP network (though the ALG cost will not be realized in
> intradomain gateway-to-gateway calls, for example). Stateless 
> proxies used
> for load sharing or fault tolerance, however, will go away, I 
> think; they'll
> be replaced by hardware load-balancers, or what have you, 
> that will provide
> scale and availability at near-router costs in latency. So, I 
> suppose from
> my perspective it is realistic to adopt the 'deploy fewer proxies'
> philosophy in the long term.
> 
> In the short term, a full second or more of post-dial delay 
> is not uncommon
> for international calls in the PSTN today. We are talking 
> about signaling
> latency, not media latency. Media latency is widely reputed 
> to be audible
> and annoying after around 250ms. Signaling latency becomes 
> problematic only
> when the cross office max is so vast that the user becomes 
> frustrated, hangs
> up and tries the call again, which generally won't happen 
> until some serious
> time has passed. That much said, I do think SIP's timers are 
> reasonable
> sized, considering that the cost of not re-transmitting when 
> a packet has
> been lost to a recoverable network error is, of course, 
> increased post-dial
> delay (for that admittedly small percentage of calls). So I 
> suppose I like
> the '100' option as a short-term solution. Sending 100 is generally a
> configurable option on proxies in my experience. It generates some
> additional busywork for the network, but certainly less so 
> than reprocessing
> INVITEs.
> 
> Jon Peterson
> Level(3) Communications
> 
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Tuesday, January 02, 2001 10:26 AM
> To: IETF SIP (E-mail)
> Subject: [SIP] Discussion of Default Timers
> 
> 
> 
> I've started to wonder about the retransmission timers 
> recommended in 2543.
> 
> The basic assumption is that VoIP networks will have 
> round-trip times of
> less than 500ms. This seems to be a valid assumptio for the 
> medai path, but
> remember -- with SIP, the SIGNALING path is not necessarily 
> thesame as the
> MEDIA path. And the timers apply to the SIGNALING path.
> 
> Many of the architectures I'm seeing have three thousand 
> kilometers, ten
> routers, and six proxies between two SIP endpoints.  Assuming 
> 6ms/1000km,
> 10ms/router, and 50ms/proxy, that works out to 418ms each 
> way, or a total of
> 836ms round trip. With default settings, the originating UA 
> is going to
> resend its INVITE after only 500ms unless response is 
> received. Everybody
> wants to use stateless proxies for performance reaons. So, 
> nearly every
> INVITE gets sent twice. This can be severely detrimental to 
> the function of
> a proxy that is operating at near peak capacity -- in fact, 
> it basically
> cuts the peak capacity of a proxy in half whenever proxy chains are
> configured in such a way that T1 is regularly exceeded.
> 
> There are a couple of alternatives that come to mind:
> 
> 1) Deploy faster proxies.
> 2) Deploy 100-generating proxies at all levels to prevent 
> timer expiration
> due to downstream latency.
> 3) Change the default timers.
> 
> Thoughts?
> 
> --
> Dean Willis
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 18:04:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23842
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 18:04:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 95C1D44349; Tue,  2 Jan 2001 17:05:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 05E9C4433E
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 17:04:09 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA15540;
	Tue, 2 Jan 2001 15:03:56 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA23620;
	Tue, 2 Jan 2001 15:03:55 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA14028;
	Tue, 2 Jan 2001 15:03:53 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, Michael Thomas <mat@cisco.com>,
        SIP List <sip@lists.bell-labs.com>
In-Reply-To: "Your message with ID" <3A525AEF.1DCDF526@cs.columbia.edu>
Message-ID: <Roam.SIMC.2.0.6.978476425.10317.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 15:00:25 -0800 (PST)


> 
> I'm still trying to understand why the act of sending SIP requests is
> subject to authorization. Will each new UDP port number and service get
> its own AAA infrastructure? (I can see authorizing resource
> reservations, but that's completely orthogonal to SIP, as has been
> discussed here a few times...)

Good question.

The carriers want to control who has access to certain services (say *traffic,
*911, etc.) Also in other cases, they want to get explicit authorization for
certain services, since they will incur a surcharge.

So when a request is received, say an invite to *traffic, a request is sent
off to the AAA server to ensure that the user is authenticated, and has access
to the said service. As far as *traffic is concerned, having traffic
information in the home network doesn't really do much good when one is
roaming :)

However, the actual services are still being worked out, and are carrier
specific. We are only trying to provide the infrastructure required to support
them.

PatC


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 18:14:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23958
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 18:14:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D3D6344346; Tue,  2 Jan 2001 17:15:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 5A99F4433E
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 17:14:34 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA13982;
	Tue, 2 Jan 2001 18:14:15 -0500 (EST)
Message-ID: <3A5260C8.6E8D9B55@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: Michael Thomas <mat@cisco.com>, SIP List <sip@lists.bell-labs.com>
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
References: <Roam.SIMC.2.0.6.978476425.10317.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 02 Jan 2001 18:14:16 -0500
Content-Transfer-Encoding: 7bit

Pat Calhoun wrote:
> 
> >
> > I'm still trying to understand why the act of sending SIP requests is
> > subject to authorization. Will each new UDP port number and service get
> > its own AAA infrastructure? (I can see authorizing resource
> > reservations, but that's completely orthogonal to SIP, as has been
> > discussed here a few times...)
> 
> Good question.
> 
> The carriers want to control who has access to certain services (say *traffic,
> *911, etc.) Also in other cases, they want to get explicit authorization for
> certain services, since they will incur a surcharge.
> 
> So when a request is received, say an invite to *traffic, a request is sent
> off to the AAA server to ensure that the user is authenticated, and has access
> to the said service. As far as *traffic is concerned, having traffic
> information in the home network doesn't really do much good when one is
> roaming :)
> 
> However, the actual services are still being worked out, and are carrier
> specific. We are only trying to provide the infrastructure required to support
> them.

Instead of re-casting the SIP request into another format and
translating status codes between protocols, why not just proxy the SIP
request to whatever database/server decides whether the person has
subscribed to this service? 

INVITE sip:traffic SIP/2.0
To: sip:traffic
From: sip:joe@othernetwork.com

(A separate question is whether non-global SIP URI are a good idea, but
that's a bit beyond this thread.)


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 23:07:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27365
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 23:07:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E538144337; Tue,  2 Jan 2001 22:08:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from hindon.hss.co.in (unknown [202.54.26.202])
	by lists.bell-labs.com (Postfix) with ESMTP id 9908044336
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 22:07:06 -0500 (EST)
Received: from hsssun01.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f0348Dl01821;
	Wed, 3 Jan 2001 09:38:14 +0530 (IST)
Received: from sampark.hss.hns.com (sampark [139.85.229.22])
	by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id f033aLK27587;
	Wed, 3 Jan 2001 09:06:21 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 652569C9.0013221C ; Wed, 3 Jan 2001 08:58:59 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: rprakash@cdotb.ernet.in
Cc: sip@lists.bell-labs.com
Message-ID: <652569C9.0013218C.00@sampark.hss.hns.com>
Subject: Re: [SIP] SIP Grammar?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 08:58:57 +0530



The definitive grammar is always in the RFC and the related drafts. Please
refer to the same.
Henning also maintains an HTMLised grammar @ http://www.cs.columbia.edu/sip
(see Grammar link at the bottom)

rp> Is it available in a form suitable
rp> from where I can build a yacc grammar easily?

These grammars cannot directly be fed into YACC or like. Sometime ago,
there was a post
saying that an ANTLR compatible grammar would be posted - but I have not
seen it yet.

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems





Prakash R <rprakash@cdotb.ernet.in> on 01/02/2001 08:25:18 PM

Please respond to rprakash@cdotb.ernet.in

To:   sip@lists.bell-labs.com
cc:

Subject:  [SIP] SIP Grammar?




Where can I find the SIP grammar? Is it available in a form suitable
from where I can build a yacc grammar easily?

NOTE: I'm new to this list. If this question has been asked earlier,
could somebody send me an email directly with the answer?

- Thanks in advance,
--
Prakash R
Co-ordinating Engineer, Internet Telephony Group
===========================================================================
C-DOT (Centre for Development of Telematics)
71/1, Sneha Complex, Miller Road, Bangalore - 560052, India
Email:rprakash@cdotb.ernet.in, Phone:+91-80-2263399, Fax:+91-80-2263256
===========================================================================

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip







_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  2 23:38:50 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27852
	for <sip-archive@odin.ietf.org>; Tue, 2 Jan 2001 23:38:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9381044337; Tue,  2 Jan 2001 22:39:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web10304.mail.yahoo.com (web10304.mail.yahoo.com [216.136.130.82])
	by lists.bell-labs.com (Postfix) with SMTP id 33C8544336
	for <SIP@lists.bell-labs.com>; Tue,  2 Jan 2001 22:38:52 -0500 (EST)
Message-ID: <20010103043841.86163.qmail@web10304.mail.yahoo.com>
Received: from [203.197.178.35] by web10304.mail.yahoo.com; Tue, 02 Jan 2001 20:38:41 PST
From: james jack <sipjames@yahoo.com>
To: SIP@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] some consultation on 181 response
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 20:38:41 -0800 (PST)

Dear All:
    I have one question to consult, on page 63 of
RFC2543bis02,one sentence is listed as the following:
"A proxy server MAY use this status code to indicate
that the call is being forwarded to a different set of
destinations".
    According to my limited knowledge, proxy server
will look up into the corresponding information of the

callee to be registered and find the next hop for one 
INVITE request or find the next hop by DNS, then under
what situation will 181 happen? Could anyone give me
some example on this?
   Thanks in advance!
   I am looking forwards to getting your answer as
soon as possible!
   Best Regards!
                       Yours: james 



__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 00:40:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28209
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 00:40:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 539A544337; Tue,  2 Jan 2001 23:41:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 1F6CE44336
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 23:40:49 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA13449;
	Wed, 3 Jan 2001 00:43:10 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBMY6>; Wed, 3 Jan 2001 00:37:38 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BFAA58AE@DYN-EXCH-001.dynamicsoft.com>
From: Igor Slepchin <ISlepchin@dynamicsoft.com>
To: Dean Willis <dean.willis@softarmor.com>,
        "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
Subject: RE: [SIP] Discussion of Default Timers
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 00:37:38 -0500

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> 
> Many of the architectures I'm seeing have three thousand 
> kilometers, ten
> routers, and six proxies between two SIP endpoints.  Assuming 
> 6ms/1000km,
> 10ms/router, and 50ms/proxy, that works out to 418ms each 
> way, or a total of
> 836ms round trip.

50ms for a stateless proxy is also rather bad. If a proxy needs that much
time to process a message, it's likely to be performing some fairly advanced
logic, hence the extra overhead of becoming stateful should be rather
minimal. I guess that's equivalent to your option 2.

---
Igor Slepchin

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 00:41:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28230
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 00:41:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 98E6544340; Tue,  2 Jan 2001 23:42:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb7.rediffmail.com (unknown [202.54.124.152])
	by lists.bell-labs.com (Postfix) with SMTP id EF95044336
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 23:41:41 -0500 (EST)
Received: (qmail 10425 invoked by uid 510); 3 Jan 2001 05:39:58 -0000
Message-ID: <20010103053958.10424.qmail@mailweb7.rediffmail.com>
MIME-Version: 1.0
To: "eburger@snowshore.com" <eburger@snowshore.com>,
        "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
Subject: RE: [SIP] a tiny binary sip proxy protocol
From: "Ashhar Farhan" <afarhan@rediffmail.com>
Content-ID: <Wed_Jan__3_11_09_58_IST_2001_0@mailweb7.rediffmail.com>
Content-type: text/plain
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 3 Jan 2001 05:39:58 -0000
Content-Transfer-Encoding: 7bit

eric wrote -
The idea of a "SIP Lite" sounds interesting.  However, what benefit do you see by having the protocol binary?  With shorts and ints, you run into network byte-order problems.

keeping the protocol binary eliminates the need for a parser completely. you can directly copy the incoming udp packet into a sip lite structure and that is it. this is exceedingly important for making sip lite easy to understand.

the network byte-order will only be a problem for the command and the version fields. the ip addresses, ports and session ids dont need to arithematically manipulate their bits, so the network byte ordering is not a problem.

- farhan@hotfoon.com


_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 05:45:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16351
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 05:45:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3B40944337; Wed,  3 Jan 2001 04:46:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from aurora.tsm.es (unknown [194.224.100.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 78DF644336
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 04:45:14 -0500 (EST)
Received: by aurora.tsm.es; (8.8.8/1.3/10May95) id LAA03888; Wed, 3 Jan 2001 11:45:17 +0100 (MET)
From: <ferreiro_j@tsm.es>
Subject: RE: [SIP] 3PCC and REFER method
To: sip@lists.bell-labs.com
Message-ID: <OFF27FC5DA.CF7B91A1-ONC12569C9.0039CF70@tsm.es>
X-MIMETrack: Serialize by Router on abantos/TSM(
 =?iso-8859-1?q?Versi=F3n_5=2E0=2E5_|Octubre_21=2C_2000=29_at_03=2F01=2F?=
 =?us-ascii?q?2001?= 11:42:56 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 11:31:34 +0100





Thank you for your reply, Eric. Comments below

>I'd worry about a third-party directing an end-point to establish a call.
>In particular, there are interesting billing issues (although one could
say
>this solves a billing issue).  For example, if the HTTP server sends the
"Go
>call the controller" message to Terminal A, the network sees a call
>origination from Terminal A.  That may, or may not, be the intention of
the
>service provider.

IMHO I do not find the billing issue as a cons for using REFER to replace
the scenario of generating two outbound calls from the controller. I cannot
imagine a SIP based network billing policy less flexible than the one
currently offered in the traditional telecom environment -i.e. with IN and
800 numbers. Anyway, in case of dealing with such a restrictive billing
policy, the controller can send the REFER to Terminal B instead, and it
makes sense with the Click-to-dial example, since the web portal will a)
own also the service representative/customer care site b) have a bussiness
relationship with the company that runs the service representative/customer
care site.

The main reason for my suggestion is to avoid the complexities related to
make the controller try to stablish two outbound calls. In the cellular
operator I work for, I just can think on one such a service currently
deployed, that is USSD-to-dial. The cellular prepaid customers when
roaming, and since the charging policy MUST be applied in real time, are
not allowed to perform explicit outbound calls (due to barrings included in
their user profile) since these calls will not be charged in the Home
Prepaid Apliccation Server; so the prepaid user is forced to send a
USSD/SMS message to the Home Prepaid Application Server including the B
number in the body text. The Home Prepaid.. acts as a controller and makes
two outbound calls to terminal B and terminal A. Due to billing constraints
-both A leg and B leg are charged to the caller, A leg is always
international, and B leg is 70% likely to belong to the home country-, the
controller makes the outbound call to B first, and if B is not reachable
(busy, disconnected, network congestion, etc.) notifies A number -tipically
SMS based-. If, and only if the second leg is properly stablished, the call
to A is performed.
This is currently the only way to perform calls for prepaid roamers in many
countries, so they have to deal with really curious scenarios:

a) the A user gets annoied when receiving a failure notification after
20-60 seconds waiting; people are more used to listen busy tones, and tend
to think the service offered is failing, it is clearly a "mediterranean"
psicological attitude :)

b)if the B number is an IVR menu (tipically when you try to reach your own
voice mailbox) since the B leg is the first leg to be stablished, the first
piece of information provided by the IVR menu is lost (imagine losing
"Press 1 to listen your messages, press 2 to change your settings")

c) User A may receive an inbound call while waiting for the controller to
stablish the A leg, i.e. busy; and reject the attempt performed by the
controller. Who should pay for the B leg already stablished? (b. t. w. a
"nice" hacking with the proposed scenario for click-to-dial is to answer a
different SDP to the RE-INVITE at the A leg as warned in
draft-rosenberg-sip-3pcc-01.txt page 12; Amazon customer representative
could be K.O. quite fast after several attacks)

It sounds to me more natural, from the A user point of view, to receive a
REFER -this means the SIP browser will interact with A in order to ask for
permission to make the outbound call- and follow the progress of the call
to B through the controller.

-b.t.w. there is a new approach to solve this prepaid roaming problem based
on Wireless IN (CAMEL) standards but this is not the point discussed here-

Anyway, there must be any other reasons not to use REFER in the 3PCC
scenario rather than billing ... or is it billing and I am wrong?

regards
Javier


>What precisely is the issue with having the controller issuing the INVITEs
>to A and B?

>> -----Original Message-----
>> From: sip-admin@lists.bell-labs.com
>> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of
>> Javier_Ferreiro_Garcia/UT03329/PLATAFORMAS_DE_SERVICIOS/TSM@tsm.es
>> Sent: Friday, December 29, 2000 6:00 AM
>> To: sip@lists.bell-labs.com
>> Subject: [SIP] 3PCC and REFER method
>>
>>
>> Hi
>> I would like to open again the issue discussed in
>> http://lists.bell-labs.com/pipermail/sip/2000q4/004739.html
>>
>> >>What happens when there is not an active SIP (INVITE) session
>> between the
>> >>referer and referee ? Sending an INVITE in this case may have unwanted
>> >>effects (like initiating a call). Are you proposing that either a) you
>> would
>> >>only send the INVITE/BYE if a corresponding SIP (INVITE) sessions
exists
>> or
>> >>b) that REFERS are not allowed outside of a SIP session?
>>
>> >  What does a REFER outside of a session mean?
>>
>> and apply this idea to the scenario proposed in
>> draft-rosenberg-sip-3pcc-01.txt Figure 1 and specifically the
>> example included for Click-to-dial application.
>>
>> In this alternative scenario for Click-to-dial, the controller, after
>> receiving the request via HTTP, do not INVITE both A and B, but
>> rather send
>> a REFER to A, asking A to INVITE the CONTROLER ITSELF. When the
controller
>> receives the INVITE SDP A from A, checks in its internal database who is
>> supposed to be contacted by A (in this case B) and sends INVITE
>> SDP A to B.
>> In this case I think the re-INVITE loop could be avoided by  applying
this
>> scenario which is more similar to a normal INVITE between two parties.
>>
>> In this alternative scenario the referer (i.e. the controller) and the
>> referee (i.e. the web-surfer) are OUTSIDE of a SIP session, but INSIDE
an
>> HTTP session. It could also be decided the referee to be the IP phone
from
>> the customer service representative, if the web-surfer IP phone
>> either does
>> not support REFER or is a PSTN endpoint.
>>
>> The reason to include as content of Refer-To header not B but the
>> controller itself is to let the controller do its job in a more
>> general way
>> (i.e. imagine click-to-dial + mid-call-announcement)
>>
>> If the scenario is not the one described for Click-to-dial, but for Mid
>> Call AnnouncementCapability, the controller does not either set
>> up the call
>> to A or send the REFER method to A, but rather receive the INVITE from A
>> and act as a "termination and reinitiation point" for control purposes
>> (i.e. disconnect and reconnect A to a media server under certain
>> conditions) as defined in draft-rosenberg-sip-3pcc-01.txt
>[snip]


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip




_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 07:15:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18282
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 07:15:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5256444338; Wed,  3 Jan 2001 06:16:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from aurora.tsm.es (unknown [194.224.100.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 6EF0144337
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 06:15:15 -0500 (EST)
Received: by aurora.tsm.es; (8.8.8/1.3/10May95) id NAA24420; Wed, 3 Jan 2001 13:15:12 +0100 (MET)
From: <ferreiro_j@tsm.es>
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, sip@lists.bell-labs.com
Message-ID: <OF205C7056.3102908A-ONC12569C9.00396361@tsm.es>
X-MIMETrack: Serialize by Router on abantos/TSM(
 =?iso-8859-1?q?Versi=F3n_5=2E0=2E5_|Octubre_21=2C_2000=29_at_03=2F01=2F?=
 =?us-ascii?q?2001?= 01:12:51 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 12:57:55 +0100




>Instead of re-casting the SIP request into another format and
>translating status codes between protocols, why not just proxy the SIP
>request to whatever database/server decides whether the person has
>subscribed to this service?

>INVITE sip:traffic SIP/2.0
>To: sip:traffic
>From: sip:joe@othernetwork.com

You are right, according to the architecture described by Adam Roach in his
presentation "SIP and 3GPP" hosted in your pages
(http://www.cs.columbia.edu/~hgs/sip/talks/SIP3GPP.ppt)
your suggestion seems to be the way 3GPP was facing this issue on August.
Have 3GPP guys changed the approach?




_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 07:57:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19594
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 07:57:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 57B5F44338; Wed,  3 Jan 2001 06:58:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.42])
	by lists.bell-labs.com (Postfix) with ESMTP id 7A3FD44336
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 06:57:51 -0500 (EST)
Received: from rami (root@varis.cs.tut.fi [130.230.4.42])
	by cs.tut.fi (8.8.8/8.8.8) with SMTP id OAA01045
	for <sip@lists.bell-labs.com>; Wed, 3 Jan 2001 14:57:39 +0200 (EET)
From: "Rami Lehtonen" <rampe@cs.tut.fi>
To: <sip@lists.bell-labs.com>
Message-ID: <LAEHIEOPJJAINNOMKENOIENGCCAA.rampe@cs.tut.fi>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Subject: [SIP] What method should be used?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 14:58:53 +0200
Content-Transfer-Encoding: 7bit

Hi all!

The SIP specification and the extensions defined for the SIP give a lot of
possible methods to be used for transferring parameters between two
end-points. In our case we are interested in transferring stream parameters
to an end-point (B) that starts the session with some third end-point (C),
see the figure below:

A  --parameter transfer-->  B  <===session===>  C

So should we use the methods like INVITE or MESSAGE (or even NOTIFY) to
deliver the parameters from A to B? Or should we define a new method for
that like JOIN, if we also want parameter negotiation between A and B?

Comments appreciated.

BR, Rami Lehtonen


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 09:06:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22211
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 09:06:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 75FA744337; Wed,  3 Jan 2001 08:07:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103])
	by lists.bell-labs.com (Postfix) with ESMTP id 53BDB44336
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 08:06:27 -0500 (EST)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-green.research.att.com (Postfix) with ESMTP id 429F01E07B
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 09:06:16 -0500 (EST)
Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id JAA00886
	for <sip@lists.bell-labs.com>; Wed, 3 Jan 2001 09:06:15 -0500 (EST)
From: William Marshall <wtm@research.att.com>
Received: (from wtm@localhost)
	by fish-ha.research.att.com (SGI-8.9.3/8.8.5) id JAA29758
	for sip@lists.bell-labs.com; Wed, 3 Jan 2001 09:05:17 -0500 (EST)
Message-Id: <200101031405.JAA29758@fish-ha.research.att.com>
To: sip@lists.bell-labs.com
Subject: RE: [SIP] Discussion of Default Timers
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 09:05:17 -0500 (EST)

Igor Slepchin wrote:
> 50ms for a stateless proxy is also rather bad. If a proxy needs that much
> time to process a message, it's likely to be performing some fairly advanced
> logic, hence the extra overhead of becoming stateful should be rather
> minimal. I guess that's equivalent to your option 2.

Proxies are not likely to be sitting idle.  If you figure instead that
10ms is the processing requirement, at a proxy that is 80% loaded
(on average when the request arrives there are 4 ahead of it in the queue)
the total transit delay through the proxy is 50ms.

Jon Peterson wrote:
> I would imagine that 'six proxy' architectures will eventually fall by the
> wayside. Today, even, I'd imagine that for most networks, the majority of
> those six proxies are either ALGs controlling FWs or stateless proxies that
> are thrown in to achieve greater scalability or availability.

I went through the scaling arguments at the WashDC meeting a little while
ago.  Basically, the proxy closest to the UA provides the IN services, and
forwards/receives requests to/from a stateless proxy at the Access Tandem.
There are 15000 Access Tandems in US.  So, if the stateless proxy could
maintain ~16000 security associations, then a 4-proxy model would work.
(There was an audible gasp in the room at this point)
It is more likely to stay at 6 to keep the IPSec overhead low.

Bill Marshall
wtm@research.att.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 09:46:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23679
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 09:46:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6030044340; Wed,  3 Jan 2001 08:47:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id 8687F44337
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 08:46:49 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 3 Jan 2001 14:46:38 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id OAA15876; Wed, 3 Jan 2001 14:45:16 GMT
Message-ID: <3A533AFC.34E31AE4@ubiquity.net>
From: Neil Deason <ndeason@ubiquity.net>
Organization: Ubiquity Software Corporation Limited
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: William Marshall <wtm@research.att.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Discussion of Default Timers
References: <200101031405.JAA29758@fish-ha.research.att.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 03 Jan 2001 14:45:16 +0000
Content-Transfer-Encoding: 7bit

William Marshall wrote:
> 
> Igor Slepchin wrote:
> > 50ms for a stateless proxy is also rather bad. If a proxy needs that much
> > time to process a message, it's likely to be performing some fairly advanced
> > logic, hence the extra overhead of becoming stateful should be rather
> > minimal. I guess that's equivalent to your option 2.
> 
> Proxies are not likely to be sitting idle.  If you figure instead that
> 10ms is the processing requirement, at a proxy that is 80% loaded
> (on average when the request arrives there are 4 ahead of it in the queue)
> the total transit delay through the proxy is 50ms.

I would hope that the server did not process requests 
sequentially.

> Jon Peterson wrote:
> > I would imagine that 'six proxy' architectures will eventually fall by the
> > wayside. Today, even, I'd imagine that for most networks, the majority of
> > those six proxies are either ALGs controlling FWs or stateless proxies that
> > are thrown in to achieve greater scalability or availability.
> 
> I went through the scaling arguments at the WashDC meeting a little while
> ago.  Basically, the proxy closest to the UA provides the IN services, and
> forwards/receives requests to/from a stateless proxy at the Access Tandem.
> There are 15000 Access Tandems in US.  So, if the stateless proxy could
> maintain ~16000 security associations, then a 4-proxy model would work.
> (There was an audible gasp in the room at this point)
> It is more likely to stay at 6 to keep the IPSec overhead low.

For the benefit of those of us not present could you
elaborate on why you would need this 6 (or 4) Proxy 
model when you could just have two proxies (outbound 
and inbound). 
Also what are the 'security associations' you refer to and 
how does the number of them potentially remove 2 proxies?
Is what you refer to here as the Access Tandem the same 
as Jon's SIP ALG - does it do anything more than firewall 
control?

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 10:03:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24362
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 10:03:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7BFAD4433D; Wed,  3 Jan 2001 09:04:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from is1-55.antd.nist.gov (is1-50.antd.nist.gov [129.6.50.251])
	by lists.bell-labs.com (Postfix) with ESMTP id 701474433A
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 09:03:24 -0500 (EST)
Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9])
	by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id JAA07188;
	Wed, 3 Jan 2001 09:55:38 -0500 (EST)
Message-ID: <3A533EB0.691886FF@nist.gov>
From: "M. Ranganathan" <mranga@nist.gov>
Reply-To: mranga@nist.gov
Organization: NIST advanced networking technologies group
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
Cc: rprakash@cdotb.ernet.in, sip@lists.bell-labs.com
Subject: Re: [SIP] SIP Grammar?
References: <652569C9.0013218C.00@sampark.hss.hns.com>
Content-Type: multipart/alternative;
 boundary="------------C063F92AB8B3E54D7C3E0B6C"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 03 Jan 2001 10:01:04 -0500


--------------C063F92AB8B3E54D7C3E0B6C
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64



Arjun:

I have constructed a parser using antlr and I have placed it available for
public download. If you visit

http://www.antd.nist.gov/proj/iptel/src/nist-sip/nist-sip-0.9/doc/index.html

You will find a link for the grammar as used in an antlr parser (in fact, as
generated using the -html switch in antlr).

If you would like to download the parser  (actually it is a little more than
just a parser)  package based on antlr, please visit our project page at:

http://www.antd.nist.gov/proj/iptel/

and click on the dowload link on the top left corner of the page.

Also, for those who are interested in vovida, we have posted some patches to
vovida to enable communication with a Netscape
browser. You can get the patches by following the link in the related works
area at the bottom of our project page.

Thanks for posting your grammar at the site you mention below.

Regards

Ranga



archow@hss.hns.com wrote:

> The definitive grammar is always in the RFC and the related drafts. Please
> refer to the same.
> Henning also maintains an HTMLised grammar @ http://www.cs.columbia.edu/sip
> (see Grammar link at the bottom)
>
> rp> Is it available in a form suitable
> rp> from where I can build a yacc grammar easily?
>
> These grammars cannot directly be fed into YACC or like. Sometime ago,
> there was a post
> saying that an ANTLR compatible grammar would be posted - but I have not
> seen it yet.
>
> Regds
> Arjun
>
> --
> Arjun Roychowdhury @ Hughes Software Systems
>
> Prakash R <rprakash@cdotb.ernet.in> on 01/02/2001 08:25:18 PM
>
> Please respond to rprakash@cdotb.ernet.in
>
> To:   sip@lists.bell-labs.com
> cc:
>
> Subject:  [SIP] SIP Grammar?
>
> Where can I find the SIP grammar? Is it available in a form suitable
> from where I can build a yacc grammar easily?
>
> NOTE: I'm new to this list. If this question has been asked earlier,
> could somebody send me an email directly with the answer?
>
> - Thanks in advance,
> --
> Prakash R
> Co-ordinating Engineer, Internet Telephony Group
> ===========================================================================
> C-DOT (Centre for Development of Telematics)
> 71/1, Sneha Complex, Miller Road, Bangalore - 560052, India
> Email:rprakash@cdotb.ernet.in, Phone:+91-80-2263399, Fax:+91-80-2263256
> ===========================================================================
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932



--------------C063F92AB8B3E54D7C3E0B6C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
&nbsp;
<br>&nbsp;
<br>Arjun:
<p>I have constructed a parser using antlr and I have placed it available
for public download. If you visit
<p><A HREF="http://www.antd.nist.gov/proj/iptel/src/nist-sip/nist-sip-0.9/doc/index.html">http://www.antd.nist.gov/proj/iptel/src/nist-sip/nist-sip-0.9/doc/index.html</A>
<p>You will find a link for the grammar as used in an antlr parser (in
fact, as generated using the -html switch in antlr).
<p>If you would like to download the parser&nbsp; (actually it is a little
more than just a parser)&nbsp; package based on antlr, please visit our
project page at:
<p><A HREF="http://www.antd.nist.gov/proj/iptel/">http://www.antd.nist.gov/proj/iptel/</A>
<p>and click on the dowload link on the top left corner of the page.
<p>Also, for those who are interested in vovida, we have posted some patches
to vovida to enable communication with a Netscape
<br>browser. You can get the patches by following the link in the related
works area at the bottom of our project page.
<p>Thanks for posting your grammar at the site you mention below.
<p>Regards
<p>Ranga
<br>&nbsp;
<br>&nbsp;
<p>archow@hss.hns.com wrote:
<blockquote TYPE=CITE>The definitive grammar is always in the RFC and the
related drafts. Please
<br>refer to the same.
<br>Henning also maintains an HTMLised grammar @ <a href="http://www.cs.columbia.edu/sip">http://www.cs.columbia.edu/sip</a>
<br>(see Grammar link at the bottom)
<p>rp> Is it available in a form suitable
<br>rp> from where I can build a yacc grammar easily?
<p>These grammars cannot directly be fed into YACC or like. Sometime ago,
<br>there was a post
<br>saying that an ANTLR compatible grammar would be posted - but I have
not
<br>seen it yet.
<p>Regds
<br>Arjun
<p>--
<br>Arjun Roychowdhury @ Hughes Software Systems
<p>Prakash R &lt;rprakash@cdotb.ernet.in> on 01/02/2001 08:25:18 PM
<p>Please respond to rprakash@cdotb.ernet.in
<p>To:&nbsp;&nbsp; sip@lists.bell-labs.com
<br>cc:
<p>Subject:&nbsp; [SIP] SIP Grammar?
<p>Where can I find the SIP grammar? Is it available in a form suitable
<br>from where I can build a yacc grammar easily?
<p>NOTE: I'm new to this list. If this question has been asked earlier,
<br>could somebody send me an email directly with the answer?
<p>- Thanks in advance,
<br>--
<br>Prakash R
<br>Co-ordinating Engineer, Internet Telephony Group
<br>===========================================================================
<br>C-DOT (Centre for Development of Telematics)
<br>71/1, Sneha Complex, Miller Road, Bangalore - 560052, India
<br>Email:rprakash@cdotb.ernet.in, Phone:+91-80-2263399, Fax:+91-80-2263256
<br>===========================================================================
<p>_______________________________________________
<br>SIP mailing list
<br>SIP@lists.bell-labs.com
<br><a href="http://lists.bell-labs.com/mailman/listinfo/sip">http://lists.bell-labs.com/mailman/listinfo/sip</a>
<p>_______________________________________________
<br>SIP mailing list
<br>SIP@lists.bell-labs.com
<br><a href="http://lists.bell-labs.com/mailman/listinfo/sip">http://lists.bell-labs.com/mailman/listinfo/sip</a></blockquote>

<pre>--&nbsp;
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.&nbsp;
Tel: 301 975 3664 Fax: 301 590 0932</pre>
&nbsp;
</body>
</html>

--------------C063F92AB8B3E54D7C3E0B6C--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 10:05:15 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24447
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 10:05:15 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A670A4434F; Wed,  3 Jan 2001 09:05:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from guardian1.tlv.radvision.com (unknown [212.143.185.30])
	by lists.bell-labs.com (Postfix) with ESMTP id 50A134434C
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 09:04:04 -0500 (EST)
Received: from nt-mail.tlv.radvision.com ([172.20.2.100])
          by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3
          release 223 ID# 0-0U10L2S100V35) with ESMTP id com
          for <sip@lists.bell-labs.com>; Wed, 3 Jan 2001 18:01:37 +0200
Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2650.21)
	id <CD80YJXF>; Wed, 3 Jan 2001 17:05:29 +0200
Message-ID: <E09383987EE5D3119F2E0008C7097728014D74A0@nt-mail.tlv.radvision.com>
From: Itamar Gilad <ItamarG@tlv.radvision.com>
To: "'SIP List'" <sip@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="WINDOWS-1255"
Subject: [SIP] open issues BOF - question
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 17:05:28 +0200

Dean, others,

Thanks for publishing the meeting minutes of the Open Issues BOF held in
San-Diego
(http://www.softarmor.com/sipwg/meets/ietf49/minutes/openissues-demirtjis.ht
m). 
Q: Is this the final thing?  It's sort of written in short-hand and I'm not
quite sure I understand what was actually decided in regard to early media.

Thanks,

Itamar Gilad
RADVision					24 Raul Wallenberg St.
itamarg@tlv.radvision.com		Building D
tel: +972 3 7659938			Tel-Aviv 69719
fax: +972 3 6442903			Israel	


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 10:12:25 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24764
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 10:12:25 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AD98E4435E; Wed,  3 Jan 2001 09:07:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by lists.bell-labs.com (Postfix) with ESMTP id 659D944337
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 16:39:05 -0500 (EST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id OAA19191;
	Tue, 2 Jan 2001 14:38:53 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA20148; Tue, 2 Jan 2001 14:38:53 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14930.22653.542206.833943@thomasm-u1.cisco.com>
To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Cc: SIP List <sip@lists.bell-labs.com>
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
In-Reply-To: <Roam.SIMC.2.0.6.978473964.32701.pcalhoun@nasnfs>
References: <20001231132059.C24183@newman.frascone.com>
	<Roam.SIMC.2.0.6.978473964.32701.pcalhoun@nasnfs>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 14:38:53 -0800 (PST)
Content-Transfer-Encoding: 7bit

Pat Calhoun writes:
 > > Thus, it is completely up to the SIP WG to
 > > define the security requirements for SIP,
 > > which may or may not require AAA functionality
 > > as a solution.
 > 
 > Correct. The 3G folks have roaming requirements, which led them to AAA. 

   I don't understand what roaming, per se, has to do
   with SIP. How is that any different than just
   REGISTER'ing to a new SIP registrar? I have
   seen people want to reuse their RADIUS
   infrastructure since it's sort of used as a
   catch all user database, but that too seems
   orthogonal to roaming and SIP.

 > > I'd note that for applications such as
 > > telephony, where the client can often be
 > > presumed to have Internet access, a wider
 > > range of security solutions are available
 > > than in network access, where by definition
 > > the client does not have network access 
 > > prior to authentication. 
 > 
 > Whether of not the client has access to the 'net or not, I believe that a set
 > of requirements needs to be spelled out. We have attempted to do so in our
 > document, with an assumption that AAA will be used to exchange authorization
 > information in roaming situations.

   That's _one_ way to do it, I suppose. It seems
   a lot more natural to do direct authentication
   of the SIP traffic on whatever device
   (including UAS's) is the target of the SIP
   message and perhaps use an LDAP or XML based
   backend to transport the database goodies. 

   The only reason I can see to shoe horn it into
   RADIUS/DIAMETER is because of legacy database
   considerations, but that's only one set of
   SIP installations which will have that as a
   large consideration.

		Mike

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 10:15:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24891
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 10:15:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BBEB744364; Wed,  3 Jan 2001 09:07:07 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by lists.bell-labs.com (Postfix) with ESMTP id D83894433E
	for <sip@lists.bell-labs.com>; Tue,  2 Jan 2001 17:11:23 -0500 (EST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id PAA02469;
	Tue, 2 Jan 2001 15:11:12 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA20155; Tue, 2 Jan 2001 15:11:11 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14930.24590.932556.999961@thomasm-u1.cisco.com>
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: Michael Thomas <mat@cisco.com>, SIP List <sip@lists.bell-labs.com>
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
In-Reply-To: <Roam.SIMC.2.0.6.978475283.27352.pcalhoun@nasnfs>
References: <14930.22653.542206.833943@thomasm-u1.cisco.com>
	<Roam.SIMC.2.0.6.978475283.27352.pcalhoun@nasnfs>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 2 Jan 2001 15:11:10 -0800 (PST)
Content-Transfer-Encoding: 7bit

Pat Calhoun writes:
 > >    I don't understand what roaming, per se, has to do
 > >    with SIP. How is that any different than just
 > >    REGISTER'ing to a new SIP registrar? I have
 > >    seen people want to reuse their RADIUS
 > >    infrastructure since it's sort of used as a
 > >    catch all user database, but that too seems
 > >    orthogonal to roaming and SIP.
 > and
 > >    That's _one_ way to do it, I suppose. It seems
 > >    a lot more natural to do direct authentication
 > >    of the SIP traffic on whatever device
 > >    (including UAS's) is the target of the SIP
 > >    message and perhaps use an LDAP or XML based
 > >    backend to transport the database goodies. 
 > > 
 > 
 > Devices can request services in foreign networks. Now perhaps
 > you are willing to open up your LDAP database to the outside world,
 > but the 3G folks aren't.

   I don't see how one database transport protocol
   or another helps you on the base administration
   problem of who is and is not allowed to see
   various pieces of data.

   I'm still having a hard time understanding what 
   this has to do with SIP. I don't need a proxy
   or anything else in the visited network to do
   anything for me SIP-wise. I can talk to my home
   proxy just like normal. The two things that I
   might need are network access and enhanced QoS
   (no access just being a degenerate case of really
   lousy QoS) from the visited network attachment
   point.

   I can understand how you might want to do AAA
   for the access part (RADIUS/DIAMETER) and 
   policy decisions for QoS, but that doesn't have
   anything to do with SIP. I'll also make the
   wild assumption that you're not thinking in
   terms of the manyfolks/DCS/DQoS draft either
   which I don't think works at all for mobile
   UA's (at least in terms of the DQoS push
   model).

			Mike

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 11:09:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26871
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 11:09:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C357D44337; Wed,  3 Jan 2001 10:10:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id CD9E444336
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 10:09:54 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24088;
	Wed, 3 Jan 2001 08:09:40 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA29442;
	Wed, 3 Jan 2001 08:09:39 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA10065;
	Wed, 3 Jan 2001 08:09:38 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, Michael Thomas <mat@cisco.com>,
        SIP List <sip@lists.bell-labs.com>
In-Reply-To: "Your message with ID" <3A5260C8.6E8D9B55@cs.columbia.edu>
Message-ID: <Roam.SIMC.2.0.6.978537966.18051.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 08:06:06 -0800 (PST)

> Instead of re-casting the SIP request into another format and
> translating status codes between protocols, why not just proxy the SIP
> request to whatever database/server decides whether the person has
> subscribed to this service? 
> 
> INVITE sip:traffic SIP/2.0
> To: sip:traffic
> From: sip:joe@othernetwork.com

For the following reasons:

1. In existing AAA networks, the home AAA server, sometimes refered to as the
AAAH, is responsible for responding with authorization information. This
authorization information typically contains a subset of the user's profile,
for a particular service.

2. Existing security relationships are setup between the AAA servers, as part
of some contractual agreement, and the carriers want to minimize such
relationships. Therefore, the number of AAA servers in the networks are MUCH
smaller than the number of SIP servers in the network.

3. Future messages between the mobile and the SIP server in the foreign
network still need to be authenticated. Once authorized, the carriers want to
minimize latency in all SIP messages for that particular session (whice occurs
due to the fact that the AAAH acts as a KDC). If a SIP server at the home
network was involved, it would have to be contacted for all future messages as
well. In topologically distant, or backhaul links that are congested, the
latency could be high.

4. If a Home SIP server approved an invite, as you suggest above, and the
foreign network could not provide the service, how would this be communicated?
In AAA, the accounting message is separate from the
authentication/authorization message to allow for such failures.

5. More reasons, if needed.

Of course, one can hack SIP to do all of the above, but the above already
works within the AAA infrastructure. Seems more logical to keep SIP as simple
as possible, and simply re-use what exists for AAA, especially if the penalty
is relatively small (e.g. translating an error code).

> (A separate question is whether non-global SIP URI are a good idea, but
> that's a bit beyond this thread.)

That's out of my league :(

PatC


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 11:11:49 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26940
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 11:11:49 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CD0DC4434C; Wed,  3 Jan 2001 10:12:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from atlgamail1.transnexus.com (transnexus.com [64.242.128.69])
	by lists.bell-labs.com (Postfix) with ESMTP id D0F6144346
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 10:11:34 -0500 (EST)
Received: from STEPHEN.transnexus.com ([192.168.1.198])
	by atlgamail1.transnexus.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02241
	for <sip@lists.bell-labs.com>; Wed, 3 Jan 2001 16:11:23 GMT
Message-Id: <5.0.2.1.2.20010103105606.00b1bb28@mail.transnexus.com>
X-Sender: sthomas@mail.transnexus.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
To: SIP List <sip@lists.bell-labs.com>
From: Stephen Thomas <stephen.thomas@transnexus.com>
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
In-Reply-To: <14930.24590.932556.999961@thomasm-u1.cisco.com>
References: <Roam.SIMC.2.0.6.978475283.27352.pcalhoun@nasnfs>
 <14930.22653.542206.833943@thomasm-u1.cisco.com>
 <Roam.SIMC.2.0.6.978475283.27352.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 03 Jan 2001 11:12:04 -0500

At 03:11 PM 2001-01-02 -0800, Michael Thomas wrote:
>    I'm still having a hard time understanding what
>    this has to do with SIP. I don't need a proxy
>    or anything else in the visited network to do
>    anything for me SIP-wise. I can talk to my home
>    proxy just like normal. The two things that I
>    might need are network access and enhanced QoS
>    (no access just being a degenerate case of really
>    lousy QoS) from the visited network attachment
>    point.

I guess it depends on whether 3G providers want to
simply sell IP access (perhaps with differentiated QoS)
or whether they want to sell transactions. Kind of
reminds me of the old days when Compuserve, Prodigy,
MCI Mail, etc. billed per email message. (I guess that
dates me.)

One assumes that there are enough smart folks in 3G
to realize that it's theoretically possible to
"envelope" a voice conversation so as to make it
indistinguishable from email, Web browsing, or any
arbitrary application (whatever is un-metered), at
least as far as the network provider is concerned. (I'll
just stick my INVITE inside an SSL-encrypted connection
to port 443.)

Maybe no handset provider would be willing to alienate
its service provider customer base by creating a sufficiently
hackable device that would allow such behavior, but,
since PDAs now have wireless voice capability, it seems like
that genie's already out of the bottle.

Stephen


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 11:27:50 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27378
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 11:27:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AC65E44350; Wed,  3 Jan 2001 10:28:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id D6B494434A
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 10:27:07 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04541;
	Wed, 3 Jan 2001 08:26:55 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA03399;
	Wed, 3 Jan 2001 08:26:53 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA10594;
	Wed, 3 Jan 2001 08:26:45 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
To: Stephen Thomas <stephen.thomas@transnexus.com>
Cc: SIP List <sip@lists.bell-labs.com>
In-Reply-To: "Your message with ID" <5.0.2.1.2.20010103105606.00b1bb28@mail.transnexus.com>
Message-ID: <Roam.SIMC.2.0.6.978538995.17272.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 08:23:15 -0800 (PST)

> I guess it depends on whether 3G providers want to
> simply sell IP access (perhaps with differentiated QoS)
> or whether they want to sell transactions. Kind of
> reminds me of the old days when Compuserve, Prodigy,
> MCI Mail, etc. billed per email message. (I guess that
> dates me.)
> 
> One assumes that there are enough smart folks in 3G
> to realize that it's theoretically possible to
> "envelope" a voice conversation so as to make it
> indistinguishable from email, Web browsing, or any
> arbitrary application (whatever is un-metered), at
> least as far as the network provider is concerned. (I'll
> just stick my INVITE inside an SSL-encrypted connection
> to port 443.)
> 
> Maybe no handset provider would be willing to alienate
> its service provider customer base by creating a sufficiently
> hackable device that would allow such behavior, but,
> since PDAs now have wireless voice capability, it seems like
> that genie's already out of the bottle.

ok, now we are venturing in the business space, so I'll temporarily cross
that boundary to address your comment.

One of my points to these carriers is that they cannot even hope that
users make use of their SIP infrastructure. There will be free SIP servers
around the 'net, and people can use those. I believe that the carriers
understand this, and this will lead to different charging models (e.g.
pay for the spectrum you use, as oppose to the calls you make or provide
better QoS if you use local SIP servers, etc.). This is really out of scope of
this discussion though...

However, some carriers do still want to make local services available,
it is not clear that there will be an added cost to make these calls, and
this is really irrelevant. The fact is that local services are important
to these providers, and an infrastructure must be built to allow them to
restrict providing these services only to customers using their network.

PatC


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 11:43:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27874
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 11:43:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9FFC044337; Wed,  3 Jan 2001 10:44:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61])
	by lists.bell-labs.com (Postfix) with ESMTP id 9119744336
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 10:43:10 -0500 (EST)
Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc363f43d50e1f2e4a3@cvis29.marconicomms.com>;
 Wed, 3 Jan 2001 16:42:55 +0000
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-30) id QAA06554; Wed, 3 Jan 2001 16:42:54 GMT
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 802569C9.005BBC7B ; Wed, 3 Jan 2001 16:42:00 +0000
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Keith Robinson" <Keith.Robinson@marconi.com>
To: Jacek_Grabiec@3com.com
Cc: sip@lists.bell-labs.com, billy@billybiggs.com, hgs@cs.columbia.edu,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>, rfairlie@nuera.com,
        jhornsby@ubiquity.net, vkg@lucent.com
Message-ID: <802569C9.005BBA5B.00@marconicomms.com>
Subject: RE: [SIP] Proxy Routing Logic
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 16:41:42 +0000



The main conflict appears to be when a call stateful proxy, which is acting as
an outbound proxy for some UAs, record routes.
The question for subsequent requests is who does the popping of the first ROUTE
entry into the R-URI ?

For the UA, the two cases are :

a) The UA pops the first route entry into the R-URI and sends to its outbound
proxy

or

b) The UA sends the request directly to its outbound proxy without modifying the
Route header and using, say, the URI in TO field as the R-URI

For case (a) the proxy (serving sipnet.com)  will see something like the
following
(Assume the original request was addressed to user1@anothernet.com)

INVITE sip:user1@anothernet.com;maddr=proxy.sipnet.com

the Route header may or may not be empty dependant on whether further
downstream proxies have record routed.

For case (b) the proxy will receive something like

INVITE sip:user1@anothernet.com
Route: <sip:user1@anothernet.com;maddr=proxy.sipnet.com>

Now,  for case (a), the request will be routed internally to the appropriate
call state machine
using the R-URI, To, From and Call-Id headers. The request will be processed and
routed to the next server
using information obtained from the original INVITE lookup, stored CONTACT or
the ROUTE header
if present.

For case (b) the request will be routed internally to the appropriate call state
machine as for
case (a). The request will be processed and routed to the next server using the
ROUTE header
which will send it back to the this proxy, identifying the same call state
machine as before; at best
this will cause the request to be processed twice, at worst it could cause
problems with state,
duplication of output etc,. The situation could be even worse if the proxy uses
rr-params to store state
information to be returned in the R-URI, perhaps for identifying spiralled call
state machines.
To stop this from happening, the proxy would have to perform some look ahead
processing on the
Route header before deciding whether or not to actually use the next Route
entry, or merely
remove it; this is special case processing on the usage of the Route header and
could become problematic if the proxy appears more than once in the Route list
due
to spiralling.


I therefore think that the UA should function as in case (a) to eliminate the
problems associated with
case (b).

Now, consider what happens when a UA operating as in case (a) sends a subsequent
request to
its outbound proxy BUT the outbound proxy has deliberately NOT record routed
because it is not
required to keep call state; however, two further downstream proxies, serving
nextsipnet.com and
furthersipnet.com, HAVE record routed.

The UA will have constructed a ROUTE header that looks something like:

Route: <sip:user2@nextsipnet.com;maddr=proxy.nextsipnet.com>
Route: <sip:user3@furthersipnet.com;maddr=proxy.furthersipnet.com>

When the UA sends a subsequent INVITE, because it functions as in case (a)
it will pop the first Route entry into the R-URI, and send this to its outbound
proxy
as it can't resolve proxy.nextsipnet.com because it has no DNS capability.

The proxy will receive the following :

INVITE sip:user2@nextsipnet.com;maddr=proxy.nextsipnet.com
Route: <sip:user3@furthersipnet.com;maddr=proxy.furthersipnet.com>

And this is the central point of the debate; should the proxy route the above
request by popping the first route entry into the R-URI, or should it use
the maddr in the R-URI received. In this case, the proxy should clearly
route the request using the maddr in the received R-URI, otherwise
proxy.nextsipnet.com will be bypassed even though it asked to be kept
in the path; this does, however, represent special case processing dependant
on the contents of the maddr.

If the UA had functioned as in case (b) for the above situation, then the proxy
would need to route using the Route header.

So, special case processing at the proxy appears unavoidable no matter
whether the UA functions as in case (a) or case (b), and whether a proxy that is
being used as an outbound proxy has record routed or not. I think the question
has
to be is what special case processing is preferable and what are  UA mandated to
do with the Route header if they wish to use an outbound proxy for subsequent
requests.

IMO, UAs using an outbound proxy should function as in case (a) and proxies
should look at the value of the received maddr before deciding whether or not
to route using the Route header if available. This provides for the simplest
rules; requiring the proxy to look at the entries in the Route header before
deciding
if it can use the first entry (situation arising through case (b) ) seems much
more complex
and prone to error.

The text in 6.34.3 is unclear as to what a UA must do if it is using an outbound
proxy; I think
it will lead to some UA functioning as in case (a) and some as in case (b) which
is the
worst scenario as it becomes almost impossible for proxies to know which
processing
to apply.

Also, considering the above and continuing my previous point on this thread
about
a roaming UA wishing to route through the context of its home domain proxy I
have the following in mind.

A UA at visitednet.com has been given proxy.visited.net as its local outbound
proxy.
The UA wishes to set up a call through its home domain proxy to
friend@anothernet.com.
The UA may well construct a Route header to get to proxy.homenet.com which looks
like:

Route <sip:friend@anothernet.com;maddr=proxy.homenet.com>

Now, a UA that functions as in case (a) will send the following to
proxy.visitednet.com

INVITE sip:friend@anothernet.com;maddr=proxy.homenet.com

The Route header will be empty, as the UA has already popped the entry
into the R-URI.

Upon receiving this request, proxy.visitednet.com (which assumes all UA do case
(a) )
will see that the maddr refererences a domain not served by itself and so
forward the
request to proxy.homenet.com, which will see the request:

INVITE sip:friend@anothernet.com;maddr=proxy.homenet.com

which is Billy's very first example on this thread.

In this case I would want proxy.homenet.com to now route using the URI
friend@anothernet.com, which was my original point.

If the UA functions as in case (b) then proxy.visitednet.com (which assumes all
UA do case (b) )
receives

INVITE sip:friend@anothernet.com
Route: <sip:friend@anothernet.com;maddr=proxy.homenet.com>

proxy.visitednet.com then pops the first Route entry into the R-URI and forwards
to proxy.homenet.com
which receives the following

INVITE sip:friend@anothernet.com;maddr=proxy.homenet.com

which is exactly the same as if the UA/proxy were functioning as in case (a).

So, to summarise, assuming UAs function as in case (a), if a proxy receives a
R-URI
with an maddr that does not reference the domain the proxy serves then the proxy
sends the request to that maddr, regardless of the Route headers; if a proxy
receives
a R-URI with an maddr that does reference the domain it serves then it strips
the maddr
and goes through the normal routing procedures. The only special case processing
is
the result of checking the maddr.

Regards,

K. Robinson.




















Jacek_Grabiec@3com.com on 02/01/2001 15:07:13
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:      sip@lists.bell-labs.com                             
                                                              
 cc:      billy@billybiggs.com, hgs@cs.columbia.edu, Jonathan 
          Rosenberg <jdrosen@dynamicsoft.com>,                
          rfairlie@nuera.com, jhornsby@ubiquity.net,          
          vkg@lucent.com(bcc: Keith Robinson/MAIN/MC1)        
                                                              
                                                              
                                                              
 Subject: RE: [SIP] Proxy Routing Logic                       
                                                              









Jonathan Rosenberg wrote;
>To comment on the primary issue, ignoring the Route header if the request
>URI domain is not your own, and sending it to that domain first, is
>dangerous, IMHO. Thats because, nearly as I can tell, it completely breaks
>the existing usage of record-routing. In the existing usage, a proxy copies
>the request URI in the request into the record-route, and adds its own
>maddr. Requests in the reverse direction will only get routed correctly
>through that same set of proxies IFF each proxy uses the top route header no
>matter what. If proxies start to only sometimes use them, we will end up
>with incorrectly routed requests.

I'm not sure if 'ignoring the Route header if the request
URI domain is not your own, and sending it to that domain first' breaks
anything.
I can see it may add another proxy to the path, but at least all record-routed
Proxies are on the path as well. Doing otherwise will break routing (I gave an
example
in one of my previuos postings). I would argue that proxy cannot blindly follow
logic 'replace RURI with Route' no matter what just like it does not proxy
responses
downstream if top-via doesn't match the server - it checks if it matches first.

>So, I would modify my proposal to satisfy some of the other requirements:

>1. If there is a Route header in a request, that ALWAYS takes priority for
>routing the request.
>2. If there is none, and the request URI has a domain NOT matching that of
>the server, but the address/domain in the maddr does, the server forwards to
>the domain in the userhost portion of the R-URI. If the neither the maddr or
>userhost have an ipaddress/domain matching the proxy, the proxy sends the
>request to the address in the maddr. Stripping of maddr is optional.

your 2 suggestion is really close what I would have in mind. There's also
another
scenario: where Proxy receives a request with maddr where neither maddr nor host
portion of RURI matches the server.

Let's say proxy at sip.company.com receives a requests like:

sip:abc@someone-else.com;maddr=proxy.com
.......
Route: <sip:123@yet-someone-else.com;maddr=yet-yet-someone-else.com>

As Billy pointed out you, being the proxy, don't really want to pop Route header
 blindly. I would rather
propose something along theses lines - it is really close to your 2 case (it
also takes care of scenario where
Proxy has it's own outbound Proxy which may have its own outbound Proxy etc - if
 you were to pop Route at
every hop the message would never get to the proper Proxies):
Investigate RURI first:
1)   if maddr exist and it doesn't match your domain send message to:
     - address indicated in maddr and strip maddr.
     - or, if outbound Proxy is used, to outbound Proxy and preserve maddr
     - or, return 488 if unwilling/unable to forward the request (I explained my
 reasoning for 488 in previous posting)
2)   if maddr exist and it matches your domain strip maddr and go to 3
3)   if host part of RURI doesn't match your domain send message to:
     - address indicated in host part of RURI and preserve existing RURI and
Route(s),
     - or, if outbound Proxy is used, to outbound Proxy and preserve existing
RURI and Route(s),
4)   if host part of RURI does match your domain pop first Route header and go
back to 1
     (now your RURI is whatever Route header contained).
5)   if there's no Route header do whatever you want (get contact from your
     location/registrar server most likely) and go back to 1 (now RURI is
whatever you got
     from location/registrar server)


regards, Jacek Grabiec
sip:jacek_grabiec@sip.3com.com



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip




_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 12:02:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28413
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 12:02:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 81BDC44345; Wed,  3 Jan 2001 11:03:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 1A62D44337
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 11:02:36 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f03H2HR28407;
	Wed, 3 Jan 2001 11:02:17 -0600 (CST)
From: siplist@fdd.com
To: sip@lists.bell-labs.com
Cc: billy@billybiggs.com, rsparks@dynamicsoft.com, sean.olson@ericsson.com,
        jdrosen@dynamicsoft.com, hgs@cs.columbia.edu, rohan@cisco.com
Message-ID: <20010103110217.A5826@fdd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [SIP] make refered-by a ?-delimited refer-to parameter
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 11:02:17 -0600


Dear SIP list,

Can we please make "referred-by" less special 
and simply another ?-delimited parameter of the 
"refer-to" to send to the target as a header?   
Thus, just like "replaces".

--
Rick
rick_dean@3com.com


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 12:04:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28476
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 12:04:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6CB9B44359; Wed,  3 Jan 2001 11:04:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id A1A1244337
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 11:03:49 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00147;
	Wed, 3 Jan 2001 09:03:36 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA12321;
	Wed, 3 Jan 2001 09:03:35 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA11765;
	Wed, 3 Jan 2001 09:03:34 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
To: Michael Thomas <mat@cisco.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        Stephen Thomas <stephen.thomas@transnexus.com>,
        SIP List <sip@lists.bell-labs.com>
In-Reply-To: "Your message with ID" <14931.22933.824401.586453@thomasm-u1.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.978541203.29620.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 09:00:03 -0800 (PST)

>    What is in scope is whether there are any
>    peculiar requirements for SIP and AAA, and
>    indeed whether AAA protocols are the right 
>    means to the end of providing cross realm
>    services at proxies and UA's. For proxies,
>    about the only advantage I can see of using
>    an outbound proxy in the visited network is
>    that it may be topologically closer which may
>    help the overall post dial delay. If it's 
>    having to make round trips to the home AAA,
>    you've probably negated that advantage, and
>    it's not clear that it's even much of an
>    advantage in other than a small subset of
>    calls.

As I mentioned, the initial AAA infrastructure is ONLY contacted once per
session (or once per user, depending upon the service and authorization
information returned from the home, I suppose). Of course accounting messages
are still sent to the home, but these do not add latency since they are done
in parallel.

> 
>    For UA's... I get the impression that there
>    is some sort of moral dividing line in the
>    AAA wg about CPE using AAA protocols. A SIP
>    UA is a SIP UA though, and since any old
>    UA may want to be able to authenticate and
>    authorize a session, it looks like this is
>    going to at the very least like duplication 
>    of capabilities that are needed for SIP UA's.
>    Since we don't even have a very good model
>    for those capabilities within SIP right now,
>    it's not clear to me that further muddying
>    the waters with AAA backhaul is going to be
>    especially productive. In fact, it will
>    probably make things much worse because of
>    protocol combinatorics.

Well, I am not sure that I really understand your comment here. In Mobile IP,
we were able to get AAA support with VERY minimal changes. In fact, the
following was done: 1. Allow the mobile to have an NAI as its identifier, as
opposed to a home address (something that is already supported in SIP, so no
change required). 2. Allow the mobile to share a secret with its AAAH, as
opposed to its Home Agent (something that is VERY easy to do, and probably
requires NO protocol changes in SIP).

>    It seems like it would be a lot simpler to just 
>    set up agreements to do SIP proxy server
>    outsourcing. You don't end up with bizarre
>    version/service skew issues that way too.

yes, and do everything that I had listed on my previous e-mail (e.g. download
a portion of the user's profile, etc.)

PatC


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 13:10:01 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00461
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 13:10:00 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B734B44337; Wed,  3 Jan 2001 12:10:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by lists.bell-labs.com (Postfix) with ESMTP id A490D44336
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 12:09:03 -0500 (EST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Wed, 3 Jan 2001 10:00:30 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 03 Jan 2001 10:01:13 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532);
	 Wed, 3 Jan 2001 10:01:13 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0
content-class: urn:content-classes:message
Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9E3@speak.dogfood>
Thread-Topic: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
Thread-Index: AcB1n7elk9DOeUgmRtORE8ASa3+tkwADi/FA
From: "Christian Huitema" <huitema@exchange.microsoft.com>
To: "Pat Calhoun" <Pat.Calhoun@eng.sun.com>,
        "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: "Michael Thomas" <mat@cisco.com>, "SIP List" <sip@lists.bell-labs.com>
X-OriginalArrivalTime: 03 Jan 2001 18:01:13.0164 (UTC) FILETIME=[28DC80C0:01C075AF]
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 10:01:12 -0800
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA00461

Pat,

There are many different ways to solve the securing of SIP exchanges,
and it is very unclear that we need to use the Radius/AAA infrastructure
in any but a limited number of cases. The basic use of SIP is
end-to-end, not tied to the network topology; there is little reason to
use the network-login credentials in the end-to-end case; this would be
about as natural as using Radius inside an e-mail client. In an
end-to-end world, we should aim primarily for public-key certicates, not
Radius like checks.

SIP already includes quite a few tools in the box, both for end-to-end
and proxy authentication. The working group is currently fighting a
creeping task overload through addition of out-of-charter items. We
should refrain from adding to that overload.

-- Christian Huitema


> -----Original Message-----
> From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> Sent: Wednesday, January 03, 2001 8:06 AM
> To: Henning G. Schulzrinne
> Cc: Pat Calhoun; Michael Thomas; SIP List
> Subject: Re: [aboba@internaut.com: Re: [SIP] 
> draft-calhoun-sip-aaa-req]
> 
> 
> > Instead of re-casting the SIP request into another format and
> > translating status codes between protocols, why not just 
> proxy the SIP
> > request to whatever database/server decides whether the person has
> > subscribed to this service? 
> > 
> > INVITE sip:traffic SIP/2.0
> > To: sip:traffic
> > From: sip:joe@othernetwork.com
> 
> For the following reasons:
> 
> 1. In existing AAA networks, the home AAA server, sometimes 
> refered to as the
> AAAH, is responsible for responding with authorization 
> information. This
> authorization information typically contains a subset of the 
> user's profile,
> for a particular service.
> 
> 2. Existing security relationships are setup between the AAA 
> servers, as part
> of some contractual agreement, and the carriers want to minimize such
> relationships. Therefore, the number of AAA servers in the 
> networks are MUCH
> smaller than the number of SIP servers in the network.
> 
> 3. Future messages between the mobile and the SIP server in 
> the foreign
> network still need to be authenticated. Once authorized, the 
> carriers want to
> minimize latency in all SIP messages for that particular 
> session (whice occurs
> due to the fact that the AAAH acts as a KDC). If a SIP server 
> at the home
> network was involved, it would have to be contacted for all 
> future messages as
> well. In topologically distant, or backhaul links that are 
> congested, the
> latency could be high.
> 
> 4. If a Home SIP server approved an invite, as you suggest 
> above, and the
> foreign network could not provide the service, how would this 
> be communicated?
> In AAA, the accounting message is separate from the
> authentication/authorization message to allow for such failures.
> 
> 5. More reasons, if needed.
> 
> Of course, one can hack SIP to do all of the above, but the 
> above already
> works within the AAA infrastructure. Seems more logical to 
> keep SIP as simple
> as possible, and simply re-use what exists for AAA, 
> especially if the penalty
> is relatively small (e.g. translating an error code).
> 
> > (A separate question is whether non-global SIP URI are a 
> good idea, but
> > that's a bit beyond this thread.)
> 
> That's out of my league :(
> 
> PatC
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 13:14:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00591
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 13:14:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7D7B74434A; Wed,  3 Jan 2001 12:15:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by lists.bell-labs.com (Postfix) with ESMTP id 9ACD84434C
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 10:56:02 -0500 (EST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id IAA13578;
	Wed, 3 Jan 2001 08:55:50 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA20417; Wed, 3 Jan 2001 08:55:50 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14931.22933.824401.586453@thomasm-u1.cisco.com>
To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Cc: Stephen Thomas <stephen.thomas@transnexus.com>,
        SIP List <sip@lists.bell-labs.com>
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
In-Reply-To: <Roam.SIMC.2.0.6.978538995.17272.pcalhoun@nasnfs>
References: <5.0.2.1.2.20010103105606.00b1bb28@mail.transnexus.com>
	<Roam.SIMC.2.0.6.978538995.17272.pcalhoun@nasnfs>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 08:55:49 -0800 (PST)
Content-Transfer-Encoding: 7bit

Pat Calhoun writes:
 > One of my points to these carriers is that they cannot even hope that
 > users make use of their SIP infrastructure. There will be free SIP servers
 > around the 'net, and people can use those. I believe that the carriers
 > understand this, and this will lead to different charging models (e.g.
 > pay for the spectrum you use, as oppose to the calls you make or provide
 > better QoS if you use local SIP servers, etc.). This is really out of scope of
 > this discussion though...

   What is in scope is whether there are any
   peculiar requirements for SIP and AAA, and
   indeed whether AAA protocols are the right 
   means to the end of providing cross realm
   services at proxies and UA's. For proxies,
   about the only advantage I can see of using
   an outbound proxy in the visited network is
   that it may be topologically closer which may
   help the overall post dial delay. If it's 
   having to make round trips to the home AAA,
   you've probably negated that advantage, and
   it's not clear that it's even much of an
   advantage in other than a small subset of
   calls.

   For UA's... I get the impression that there
   is some sort of moral dividing line in the
   AAA wg about CPE using AAA protocols. A SIP
   UA is a SIP UA though, and since any old
   UA may want to be able to authenticate and
   authorize a session, it looks like this is
   going to at the very least like duplication 
   of capabilities that are needed for SIP UA's.
   Since we don't even have a very good model
   for those capabilities within SIP right now,
   it's not clear to me that further muddying
   the waters with AAA backhaul is going to be
   especially productive. In fact, it will
   probably make things much worse because of
   protocol combinatorics.
  
 > However, some carriers do still want to make local services available,
 > it is not clear that there will be an added cost to make these calls, and
 > this is really irrelevant. The fact is that local services are important
 > to these providers, and an infrastructure must be built to allow them to
 > restrict providing these services only to customers using their network.

   It seems like it would be a lot simpler to just 
   set up agreements to do SIP proxy server
   outsourcing. You don't end up with bizarre
   version/service skew issues that way too.

		Mike

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 13:16:33 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00684
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 13:16:33 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DC74E4435A; Wed,  3 Jan 2001 12:15:07 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by lists.bell-labs.com (Postfix) with ESMTP id DEB9344336
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 11:42:17 -0500 (EST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id JAA14620;
	Wed, 3 Jan 2001 09:42:04 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA20424; Wed, 3 Jan 2001 09:42:04 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14931.25708.455779.464579@thomasm-u1.cisco.com>
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Cc: Michael Thomas <mat@cisco.com>,
        Stephen Thomas <stephen.thomas@transnexus.com>,
        SIP List <sip@lists.bell-labs.com>
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
In-Reply-To: <Roam.SIMC.2.0.6.978541203.29620.pcalhoun@nasnfs>
References: <14931.22933.824401.586453@thomasm-u1.cisco.com>
	<Roam.SIMC.2.0.6.978541203.29620.pcalhoun@nasnfs>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 09:42:04 -0800 (PST)
Content-Transfer-Encoding: 7bit

Pat Calhoun writes:
 > >    What is in scope is whether there are any
 > >    peculiar requirements for SIP and AAA, and
 > >    indeed whether AAA protocols are the right 
 > >    means to the end of providing cross realm
 > >    services at proxies and UA's. For proxies,
 > >    about the only advantage I can see of using
 > >    an outbound proxy in the visited network is
 > >    that it may be topologically closer which may
 > >    help the overall post dial delay. If it's 
 > >    having to make round trips to the home AAA,
 > >    you've probably negated that advantage, and
 > >    it's not clear that it's even much of an
 > >    advantage in other than a small subset of
 > >    calls.
 > 
 > As I mentioned, the initial AAA infrastructure is ONLY contacted once per
 > session (or once per user, depending upon the service and authorization
 > information returned from the home, I suppose). Of course accounting messages
 > are still sent to the home, but these do not add latency since they are done
 > in parallel.
 > 
 > > 
 > >    For UA's... I get the impression that there
 > >    is some sort of moral dividing line in the
 > >    AAA wg about CPE using AAA protocols. A SIP
 > >    UA is a SIP UA though, and since any old
 > >    UA may want to be able to authenticate and
 > >    authorize a session, it looks like this is
 > >    going to at the very least like duplication 
 > >    of capabilities that are needed for SIP UA's.
 > >    Since we don't even have a very good model
 > >    for those capabilities within SIP right now,
 > >    it's not clear to me that further muddying
 > >    the waters with AAA backhaul is going to be
 > >    especially productive. In fact, it will
 > >    probably make things much worse because of
 > >    protocol combinatorics.
 > 
 > Well, I am not sure that I really understand your comment here. In Mobile IP,
 > we were able to get AAA support with VERY minimal changes. 

   The problem is that you're proposing to
   backhaul most (all?) of the SIP message 
   back as an opaque blob. That sort of begs
   the question of why don't you just send it
   as a SIP message as Henning suggests; the
   AAA is, if nothing else, going to have quite
   a bit of proxy logic to determine whether
   it should authorize the request. Looks like
   duck, walks like duck... probably is duck.

 > In fact, the
 > following was done: 1. Allow the mobile to have an NAI as its identifier, as
 > opposed to a home address (something that is already supported in SIP, so no
 > change required). 2. Allow the mobile to share a secret with its AAAH, as
 > opposed to its Home Agent (something that is VERY easy to do, and probably
 > requires NO protocol changes in SIP).

   I assume that you're talking about
   draft-ietf-mobileip-aaa-key-01.txt? Assuming that I'm
   reading the draft correctly, I have to tell you that the
   entire idea makes me extremely queasy: shipping the user's
   long term key from the AAA to other entities of
   which have questionable and/or unknown security
   practices seems *extremely* dangerous.

   Kerberos, for this very reason, does not do this; instead
   a short term ephemeral secret is created for use between
   the client and server. That you even call the AAAH
   a "KDC" (to which I don't disagree) should give pause
   that the AAA should at least learn the lessons of "real"
   KDC's which consumes endless hours of lots of
   smart security folks. FYI, I'm in the process
   of writing a draft which has the functionality
   you're looking for but uses Kerberos mechanisms 
   to create an ephemeral session key. 

	     Mike

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 13:22:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00877
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 13:22:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0D77D44364; Wed,  3 Jan 2001 12:23:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by lists.bell-labs.com (Postfix) with ESMTP id 87D1944362
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 12:22:33 -0500 (EST)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f03IKW113948;
	Wed, 3 Jan 2001 10:20:32 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104])
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f03ILWB07497;
	Wed, 3 Jan 2001 10:21:32 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569C9.0064F84F ; Wed, 3 Jan 2001 10:22:51 -0800
X-Lotus-FromDomain: 3COM
From: Jacek_Grabiec@3com.com
To: Keith.Robinson@marconi.com
Cc: sip@lists.bell-labs.com, billy@billybiggs.com, hgs@cs.columbia.edu,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>, rfairlie@nuera.com,
        jhornsby@ubiquity.net, vkg@lucent.com
Message-ID: <882569C9.0064F2F8.00@hqoutbound.ops.3com.com>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] (no subject)
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 12:23:38 -0600



Keith wrote:
>The main conflict appears to be when a call stateful proxy, which is acting as
>an outbound proxy for some UAs, record routes.
>The question for subsequent requests is who does the popping of the first ROUTE
>entry into the R-URI ?

>For the UA, the two cases are :

>a) The UA pops the first route entry into the R-URI and sends to its outbound
>proxy

That is to me obvious and correct behavior in all cases.


>or

>b) The UA sends the request directly to its outbound proxy without modifying
the
>Route header and using, say, the URI in TO field as the R-URI

>For case (a) the proxy (serving sipnet.com)  will see something like the
>following
>(Assume the original request was addressed to user1@anothernet.com)

>INVITE sip:user1@anothernet.com;maddr=proxy.sipnet.com

That is complete news to me, it doesn't really solve anything and, as Keith
points
out, leads to many problems. So do not do that.

>.........
>.........

>Now, consider what happens when a UA operating as in case (a) sends a
subsequent
>request to
>its outbound proxy BUT the outbound proxy has deliberately NOT record routed
>because it is not
>required to keep call state; however, two further downstream proxies, serving
>nextsipnet.com and
>furthersipnet.com, HAVE record routed.


just to clarify, I'm assuming sipnet.com is an outbound proxy not doing RR, then
anothernet.com is a proxy not doing RR either (since original request was
user1@anothernet.com anothernet.com proxy has to be in the path somewhere) which
forwarded request to user2@nextsipnet.com. So we really an outbound proxy plus
three downstream proxies, two with RR one without. Right?


>The UA will have constructed a ROUTE header that looks something like:
>
>Route: <sip:user2@nextsipnet.com;maddr=proxy.nextsipnet.com>
>Route: <sip:user3@furthersipnet.com;maddr=proxy.furthersipnet.com>
>
>When the UA sends a subsequent INVITE, because it functions as in case (a)
>it will pop the first Route entry into the R-URI, and send this to its outbound
>proxy
>as it can't resolve proxy.nextsipnet.com because it has no DNS capability.
>
>The proxy will receive the following :

>INVITE sip:user2@nextsipnet.com;maddr=proxy.nextsipnet.com
>Route: <sip:user3@furthersipnet.com;maddr=proxy.furthersipnet.com>
>
>And this is the central point of the debate; should the proxy route the above
>request by popping the first route entry into the R-URI, or should it use
>the maddr in the R-URI received.In this case, the proxy should clearly
>route the request using the maddr in the received R-URI, otherwise
>proxy.nextsipnet.com will be bypassed even though it asked to be kept
>in the path; this does, however, represent special case processing dependant
>on the contents of the maddr.


Indeed, that's the main point of this thread. The bahavior you are presenting
is the one Billy and me are arguing for all along - do not insert Route blindly.


>If the UA had functioned as in case (b) for the above situation, then the proxy
>would need to route using the Route header.

But I think it is clear UA should never behave as in case b) so it is not an
issue.


>So, special case processing at the proxy appears unavoidable no matter
>whether the UA functions as in case (a) or case (b), and whether a proxy that
is
>being used as an outbound proxy has record routed or not. I think the question
>has
>to be is what special case processing is preferable and what are  UA mandated
to
>do with the Route header if they wish to use an outbound proxy for subsequent
>requests.

>IMO, UAs using an outbound proxy should function as in case (a) and proxies
>should look at the value of the received maddr before deciding whether or not
>to route using the Route header if available. This provides for the simplest
>rules; requiring the proxy to look at the entries in the Route header before
>deciding
>if it can use the first entry (situation arising through case (b) ) seems much
>more complex
>and prone to error.

That's where I beg to differ. I do not think any special case processing is
needed - why does the proxy need to look into Route headers BEFORE deciding
if it can use the first entry? Did I miss something?

>...
>...


>So, to summarise, assuming UAs function as in case (a), if a proxy receives a
>R-URI
>with an maddr that does not reference the domain the proxy serves then the
proxy
>sends the request to that maddr, regardless of the Route headers; if a proxy
>receives
>a R-URI with an maddr that does reference the domain it serves then it strips
>the maddr
>and goes through the normal routing procedures. The only special case
processing
>is
>the result of checking the maddr.
>Regards,
>
>K. Robinson.

That seems to be exactly the logic I'm for (please see my previous posting). I
would
argue it is not a special behavior: it only makes sense to me that the Proxy
should
check if the message is for it (by investigating maddr and/or RURI as proposed)
before
doing anything. I can agree however, that it is not clearly stated in the spec
and one
may have an impression Proxy should always pop the first Route regardless

regards, Jacek Grabiec





_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 13:36:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01284
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 13:36:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 63EAB44341; Wed,  3 Jan 2001 12:37:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.itvista.com (unknown [12.44.179.200])
	by lists.bell-labs.com (Postfix) with ESMTP id 96ECF44339
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 12:36:47 -0500 (EST)
Received: from david (w040.z208176180.sjc-ca.dsl.cnc.net [208.176.180.40])
	by mail.itvista.com (Build 101 8.9.3/NT-8.9.3) with SMTP id KAA00822
	for <sip@lists.bell-labs.com>; Wed, 03 Jan 2001 10:34:31 -0800
From: "David Israel" <david@ipunity.com>
To: <sip@lists.bell-labs.com>
Message-ID: <NDBBJAJIAKKPFPCADBPMMEGBCKAA.david@ipunity.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: [SIP] Setting Via field in Responses
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 10:39:38 -0800
Content-Transfer-Encoding: 7bit


The spec says that the Via field in a Response is to be set to the client or
proxy processing the message. So if you are sending the response back to the
proxy you received the request from, you would just copy over the top-most
Via field from the Request to the Response. But what happens if there is a
Contact field in the Request, and you are sending the Response to the URI
from the Contact field? Does the Via field in the Response in this case have
the URI from the Contact in the Request?

Thank you,
David


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 14:22:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02573
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 14:22:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1924444337; Wed,  3 Jan 2001 13:23:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net [208.37.18.67])
	by lists.bell-labs.com (Postfix) with ESMTP id 1695944336
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 13:22:58 -0500 (EST)
Received: from matt.ipverse.com (lsanca1-ar5-208-228.dsl.gtei.net [4.33.208.228]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZV8K8CKS; Wed, 3 Jan 2001 11:22:46 -0800
Message-Id: <5.0.2.1.2.20010103111702.02174b40@pop3.ipverse.com>
X-Sender: matt@ipverse.com@pop3.ipverse.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
To: "Christian Huitema" <huitema@exchange.microsoft.com>,
        "Pat Calhoun" <Pat.Calhoun@eng.sun.com>
From: Matt Holdrege <matt@ipverse.com>
Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
Cc: sip@lists.bell-labs.com
In-Reply-To: <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9E3@speak.dogfood>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 03 Jan 2001 11:22:42 -0800

At 10:01 AM 1/3/2001, Christian Huitema wrote:
>Pat,
>
>There are many different ways to solve the securing of SIP exchanges,
>and it is very unclear that we need to use the Radius/AAA infrastructure
>in any but a limited number of cases. The basic use of SIP is
>end-to-end, not tied to the network topology; there is little reason to
>use the network-login credentials in the end-to-end case; this would be
>about as natural as using Radius inside an e-mail client. In an
>end-to-end world, we should aim primarily for public-key certicates, not
>Radius like checks.

It's not simply authorizing a call, as you say that can be end-to-end. But 
advanced services from any type of IP server (or even an IN SCP 
potentially, speaking SIGTRAN perhaps) could be involved in a SIP call. 
Each instance of a service being provided may need to be authorized and 
accounted for and the user must be authenticated. In certain networks a 
significant back-end system will handle AAA for such user actions.

>SIP already includes quite a few tools in the box, both for end-to-end
>and proxy authentication. The working group is currently fighting a
>creeping task overload through addition of out-of-charter items. We
>should refrain from adding to that overload.

I don't think anyone is proposing adding to or modifying SIP. Rather we are 
collecting AAA requirements from the people who should know the best how 
SIP networks will be deployed.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 14:30:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02726
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 14:30:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7B1744434A; Wed,  3 Jan 2001 13:31:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from selene.cps.intel.com (selene.cps.intel.com [192.198.165.10])
	by lists.bell-labs.com (Postfix) with ESMTP id CB3CA44337
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 13:30:50 -0500 (EST)
Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204])
	by selene.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id LAA26347
	for <sip@lists.bell-labs.com>; Wed, 3 Jan 2001 11:30:39 -0800 (PST)
Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.204
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 03 Jan 2001 19:30:38 0000 (GMT)
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <Z4N0QRD5>; Wed, 3 Jan 2001 11:30:37 -0800
Message-ID: <4148FEAAD879D311AC5700A0C969E8902D4908@orsmsx35.jf.intel.com>
From: "Gross, Gerhard" <gerhard.gross@intel.com>
To: SIP List <sip@lists.bell-labs.com>
Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 11:30:31 -0800

> In an end-to-end world, we should aim primarily
> for public-key certicates, not Radius like checks.

As discussed in
http://search.ietf.org/internet-drafts/draft-gross-sipaq-00.txt

Gery

        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        X                                         X
        X    Gerhard W. Gross, Ph.D.              X
        X    Intel                                X
        X    2111 NE 25th Ave                     X
        X    Hillsboro, OR 97124-5961, USA        X
        X    Policy Architecture Group            X
        X      - Internet and Communication Lab   X
        X    phone:    (503) 264-6389             X
        X    fax:      (503) 264-3483             X
        X    email:    gerhard.gross@intel.com    X
        X                                         X
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


> -----Original Message-----
> From: Christian Huitema [mailto:huitema@exchange.microsoft.com]
> Sent: Wednesday, January 03, 2001 10:01 AM
> To: Pat Calhoun; Henning G. Schulzrinne
> Cc: Michael Thomas; SIP List
> Subject: RE: [aboba@internaut.com: Re: [SIP] 
> draft-calhoun-sip-aaa-req]
> 
> 
> Pat,
> 
> There are many different ways to solve the securing of SIP exchanges,
> and it is very unclear that we need to use the Radius/AAA 
> infrastructure
> in any but a limited number of cases. The basic use of SIP is
> end-to-end, not tied to the network topology; there is little 
> reason to
> use the network-login credentials in the end-to-end case; 
> this would be
> about as natural as using Radius inside an e-mail client. In an
> end-to-end world, we should aim primarily for public-key 
> certicates, not
> Radius like checks.
> 
> SIP already includes quite a few tools in the box, both for end-to-end
> and proxy authentication. The working group is currently fighting a
> creeping task overload through addition of out-of-charter items. We
> should refrain from adding to that overload.
> 
> -- Christian Huitema
> 
> 
> > -----Original Message-----
> > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> > Sent: Wednesday, January 03, 2001 8:06 AM
> > To: Henning G. Schulzrinne
> > Cc: Pat Calhoun; Michael Thomas; SIP List
> > Subject: Re: [aboba@internaut.com: Re: [SIP] 
> > draft-calhoun-sip-aaa-req]
> > 
> > 
> > > Instead of re-casting the SIP request into another format and
> > > translating status codes between protocols, why not just 
> > proxy the SIP
> > > request to whatever database/server decides whether the person has
> > > subscribed to this service? 
> > > 
> > > INVITE sip:traffic SIP/2.0
> > > To: sip:traffic
> > > From: sip:joe@othernetwork.com
> > 
> > For the following reasons:
> > 
> > 1. In existing AAA networks, the home AAA server, sometimes 
> > refered to as the
> > AAAH, is responsible for responding with authorization 
> > information. This
> > authorization information typically contains a subset of the 
> > user's profile,
> > for a particular service.
> > 
> > 2. Existing security relationships are setup between the AAA 
> > servers, as part
> > of some contractual agreement, and the carriers want to 
> minimize such
> > relationships. Therefore, the number of AAA servers in the 
> > networks are MUCH
> > smaller than the number of SIP servers in the network.
> > 
> > 3. Future messages between the mobile and the SIP server in 
> > the foreign
> > network still need to be authenticated. Once authorized, the 
> > carriers want to
> > minimize latency in all SIP messages for that particular 
> > session (whice occurs
> > due to the fact that the AAAH acts as a KDC). If a SIP server 
> > at the home
> > network was involved, it would have to be contacted for all 
> > future messages as
> > well. In topologically distant, or backhaul links that are 
> > congested, the
> > latency could be high.
> > 
> > 4. If a Home SIP server approved an invite, as you suggest 
> > above, and the
> > foreign network could not provide the service, how would this 
> > be communicated?
> > In AAA, the accounting message is separate from the
> > authentication/authorization message to allow for such failures.
> > 
> > 5. More reasons, if needed.
> > 
> > Of course, one can hack SIP to do all of the above, but the 
> > above already
> > works within the AAA infrastructure. Seems more logical to 
> > keep SIP as simple
> > as possible, and simply re-use what exists for AAA, 
> > especially if the penalty
> > is relatively small (e.g. translating an error code).
> > 
> > > (A separate question is whether non-global SIP URI are a 
> > good idea, but
> > > that's a bit beyond this thread.)
> > 
> > That's out of my league :(
> > 
> > PatC
> > 
> > 
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 14:45:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03056
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 14:45:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 263AE4434A; Wed,  3 Jan 2001 13:46:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.itvista.com (unknown [12.44.179.200])
	by lists.bell-labs.com (Postfix) with ESMTP id 08D2C44336
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 13:45:01 -0500 (EST)
Received: from Hunter (w040.z208176180.sjc-ca.dsl.cnc.net [208.176.180.40])
	by mail.itvista.com (Build 101 8.9.3/NT-8.9.3) with SMTP id LAA00942;
	Wed, 03 Jan 2001 11:42:40 -0800
From: "Tom Tang" <ttang@ipunity.com>
To: "Gross, Gerhard" <gerhard.gross@intel.com>,
        "SIP List" <sip@lists.bell-labs.com>
Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
Message-ID: <NEBBKKNJKLFFANNILOELCEBLCCAA.ttang@ipunity.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <4148FEAAD879D311AC5700A0C969E8902D4908@orsmsx35.jf.intel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 11:41:19 -0800
Content-Transfer-Encoding: 7bit


  I'm curious as to why everybody is stating that SIP is an end-to-end 
 protocol.  SIP proxies may need to modify SIP message payloads AFAIK.
 If this is true, don't we also need AAA on a PHB ?  Cheers.

 - Tom Tang

-----Original Message-----
From: sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Gross, Gerhard
Sent: Wednesday, January 03, 2001 11:31 AM
To: SIP List
Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]


> In an end-to-end world, we should aim primarily
> for public-key certicates, not Radius like checks.

As discussed in
http://search.ietf.org/internet-drafts/draft-gross-sipaq-00.txt

Gery

        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        X                                         X
        X    Gerhard W. Gross, Ph.D.              X
        X    Intel                                X
        X    2111 NE 25th Ave                     X
        X    Hillsboro, OR 97124-5961, USA        X
        X    Policy Architecture Group            X
        X      - Internet and Communication Lab   X
        X    phone:    (503) 264-6389             X
        X    fax:      (503) 264-3483             X
        X    email:    gerhard.gross@intel.com    X
        X                                         X
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


> -----Original Message-----
> From: Christian Huitema [mailto:huitema@exchange.microsoft.com]
> Sent: Wednesday, January 03, 2001 10:01 AM
> To: Pat Calhoun; Henning G. Schulzrinne
> Cc: Michael Thomas; SIP List
> Subject: RE: [aboba@internaut.com: Re: [SIP] 
> draft-calhoun-sip-aaa-req]
> 
> 
> Pat,
> 
> There are many different ways to solve the securing of SIP exchanges,
> and it is very unclear that we need to use the Radius/AAA 
> infrastructure
> in any but a limited number of cases. The basic use of SIP is
> end-to-end, not tied to the network topology; there is little 
> reason to
> use the network-login credentials in the end-to-end case; 
> this would be
> about as natural as using Radius inside an e-mail client. In an
> end-to-end world, we should aim primarily for public-key 
> certicates, not
> Radius like checks.
> 
> SIP already includes quite a few tools in the box, both for end-to-end
> and proxy authentication. The working group is currently fighting a
> creeping task overload through addition of out-of-charter items. We
> should refrain from adding to that overload.
> 
> -- Christian Huitema
> 
> 
> > -----Original Message-----
> > From: Pat Calhoun [mailto:Pat.Calhoun@eng.sun.com]
> > Sent: Wednesday, January 03, 2001 8:06 AM
> > To: Henning G. Schulzrinne
> > Cc: Pat Calhoun; Michael Thomas; SIP List
> > Subject: Re: [aboba@internaut.com: Re: [SIP] 
> > draft-calhoun-sip-aaa-req]
> > 
> > 
> > > Instead of re-casting the SIP request into another format and
> > > translating status codes between protocols, why not just 
> > proxy the SIP
> > > request to whatever database/server decides whether the person has
> > > subscribed to this service? 
> > > 
> > > INVITE sip:traffic SIP/2.0
> > > To: sip:traffic
> > > From: sip:joe@othernetwork.com
> > 
> > For the following reasons:
> > 
> > 1. In existing AAA networks, the home AAA server, sometimes 
> > refered to as the
> > AAAH, is responsible for responding with authorization 
> > information. This
> > authorization information typically contains a subset of the 
> > user's profile,
> > for a particular service.
> > 
> > 2. Existing security relationships are setup between the AAA 
> > servers, as part
> > of some contractual agreement, and the carriers want to 
> minimize such
> > relationships. Therefore, the number of AAA servers in the 
> > networks are MUCH
> > smaller than the number of SIP servers in the network.
> > 
> > 3. Future messages between the mobile and the SIP server in 
> > the foreign
> > network still need to be authenticated. Once authorized, the 
> > carriers want to
> > minimize latency in all SIP messages for that particular 
> > session (whice occurs
> > due to the fact that the AAAH acts as a KDC). If a SIP server 
> > at the home
> > network was involved, it would have to be contacted for all 
> > future messages as
> > well. In topologically distant, or backhaul links that are 
> > congested, the
> > latency could be high.
> > 
> > 4. If a Home SIP server approved an invite, as you suggest 
> > above, and the
> > foreign network could not provide the service, how would this 
> > be communicated?
> > In AAA, the accounting message is separate from the
> > authentication/authorization message to allow for such failures.
> > 
> > 5. More reasons, if needed.
> > 
> > Of course, one can hack SIP to do all of the above, but the 
> > above already
> > works within the AAA infrastructure. Seems more logical to 
> > keep SIP as simple
> > as possible, and simply re-use what exists for AAA, 
> > especially if the penalty
> > is relatively small (e.g. translating an error code).
> > 
> > > (A separate question is whether non-global SIP URI are a 
> > good idea, but
> > > that's a bit beyond this thread.)
> > 
> > That's out of my league :(
> > 
> > PatC
> > 
> > 
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 15:00:50 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03441
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 15:00:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8AA9D44349; Wed,  3 Jan 2001 14:01:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11])
	by lists.bell-labs.com (Postfix) with ESMTP id E4A6344344
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 14:00:35 -0500 (EST)
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id UAA13109
	for <sip@lists.bell-labs.com>; Wed, 3 Jan 2001 20:01:35 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 03 Jan 2001 20:00:13 0000 (GMT)
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <CGAPCT0X>; Wed, 3 Jan 2001 12:00:12 -0800
Message-ID: <4148FEAAD879D311AC5700A0C969E8902D490A@orsmsx35.jf.intel.com>
From: "Gross, Gerhard" <gerhard.gross@intel.com>
To: sip@lists.bell-labs.com
Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 12:00:01 -0800

>Instead of re-casting the SIP request into another format and
>translating status codes between protocols, why not just proxy the SIP
>request to whatever database/server decides whether the person has
>subscribed to this service?

One reason is for simplicity and to potentially
increase processing speed. This is done by taking
advantage of the SIP parser already built into
the SIP proxy. If the whole SIP message were
just forwarded as is to the PDP (policy decision
point), the PDP would need some sort of SIP
parser (thus adding complexity/redundancy to
the chain).

On the other hand, while the SIP proxy parses the
SIP message, it may extract certain information
from it and put it in a simpler and smaller structure
to be passed on to the PDP (AAA/policy server). Such
a structure/protocol has been defined in
http://search.ietf.org/internet-drafts/draft-gross-cops-sip-00.txt.

Gery

        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        X                                         X
        X    Gerhard W. Gross, Ph.D.              X
        X    Intel                                X
        X    2111 NE 25th Ave                     X
        X    Hillsboro, OR 97124-5961, USA        X
        X    Policy Architecture Group            X
        X      - Internet and Communication Lab   X
        X    phone:    (503) 264-6389             X
        X    fax:      (503) 264-3483             X
        X    email:    gerhard.gross@intel.com    X
        X                                         X
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 15:09:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03692
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 15:09:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1F30F44349; Wed,  3 Jan 2001 14:10:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by lists.bell-labs.com (Postfix) with ESMTP id BC33544349
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 14:02:50 -0500 (EST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id MAA18273;
	Wed, 3 Jan 2001 12:02:38 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA20441; Wed, 3 Jan 2001 12:02:37 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14931.34141.709436.40924@thomasm-u1.cisco.com>
To: Matt Holdrege <matt@ipverse.com>
Cc: "Christian Huitema" <huitema@exchange.microsoft.com>,
        "Pat Calhoun" <Pat.Calhoun@eng.sun.com>, sip@lists.bell-labs.com
Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
In-Reply-To: <5.0.2.1.2.20010103111702.02174b40@pop3.ipverse.com>
References: <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9E3@speak.dogfood>
	<5.0.2.1.2.20010103111702.02174b40@pop3.ipverse.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 12:02:37 -0800 (PST)
Content-Transfer-Encoding: 7bit

Matt Holdrege writes:
 > At 10:01 AM 1/3/2001, Christian Huitema wrote:
 > >Pat,
 > >
 > >There are many different ways to solve the securing of SIP exchanges,
 > >and it is very unclear that we need to use the Radius/AAA infrastructure
 > >in any but a limited number of cases. The basic use of SIP is
 > >end-to-end, not tied to the network topology; there is little reason to
 > >use the network-login credentials in the end-to-end case; this would be
 > >about as natural as using Radius inside an e-mail client. In an
 > >end-to-end world, we should aim primarily for public-key certicates, not
 > >Radius like checks.
 > 
 > It's not simply authorizing a call, as you say that can be end-to-end. But 
 > advanced services from any type of IP server (or even an IN SCP 
 > potentially, speaking SIGTRAN perhaps) could be involved in a SIP call. 
 > Each instance of a service being provided may need to be authorized and 
 > accounted for and the user must be authenticated. In certain networks a 
 > significant back-end system will handle AAA for such user actions.

   Again, you _could_ do that, but you could just as easily
   build the authentication/authorization logic into the
   proxy/UA. NAS routers typically do not have or
   want a disk and/or programming environment. I
   don't think the same set of constraints are
   pertinent to SIP. Indeed, it seems to be quite
   the opposite.

	    Mike

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 15:27:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04078
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 15:27:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7429844338; Wed,  3 Jan 2001 14:28:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by lists.bell-labs.com (Postfix) with ESMTP id 09B6C44336
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 14:27:36 -0500 (EST)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch2.nortel.com; Wed, 3 Jan 2001 14:22:08 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <Z8FFQQ14>; Wed, 3 Jan 2001 14:26:44 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43AA5D45@crchy271.us.nortel.com>
From: "Brian Stucker" <bstucker@nortelnetworks.com>
To: Ashhar Farhan <afarhan@rediffmail.com>
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] a tiny binary sip proxy protocol
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C075C3.77F52180"
X-Orig: <bstucker@americasm01.nt.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 14:26:35 -0600

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_01C075C3.77F52180
Content-Type: text/plain;
	charset="iso-8859-1"

Hmm... Some machines use big-endian formats for their bytes, and others
little-endian. So you still have the problem of which bit of a byte is
considered most significant.

Intel uses little-endian, in which the leftmost bit is the least
significant. Other manufacturers use big-endian in which the rightmost bit
is the least significant.

So just copying bits off of a NIC into a struct of some sort, without regard
to the formatting of those bits, even within a single byte, can be
problematic.

Brian



-----Original Message-----
From: Ashhar Farhan [mailto:afarhan@rediffmail.com]
Sent: Tuesday, January 02, 2001 11:40 PM
Subject: RE: [SIP] a tiny binary sip proxy protocol


eric wrote -
The idea of a "SIP Lite" sounds interesting.  However, what benefit do you
see by having the protocol binary?  With shorts and ints, you run into
network byte-order problems.

keeping the protocol binary eliminates the need for a parser completely. you
can directly copy the incoming udp packet into a sip lite structure and that
is it. this is exceedingly important for making sip lite easy to understand.

the network byte-order will only be a problem for the command and the
version fields. the ip addresses, ports and session ids dont need to
arithematically manipulate their bits, so the network byte ordering is not a
problem.

- farhan@hotfoon.com


_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C075C3.77F52180
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [SIP] a tiny binary sip proxy protocol</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hmm... Some machines use big-endian formats for their =
bytes, and others little-endian. So you still have the problem of which =
bit of a byte is considered most significant.</FONT></P>

<P><FONT SIZE=3D2>Intel uses little-endian, in which the leftmost bit =
is the least significant. Other manufacturers use big-endian in which =
the rightmost bit is the least significant.</FONT></P>

<P><FONT SIZE=3D2>So just copying bits off of a NIC into a struct of =
some sort, without regard to the formatting of those bits, even within =
a single byte, can be problematic.</FONT></P>

<P><FONT SIZE=3D2>Brian</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ashhar Farhan [<A =
HREF=3D"mailto:afarhan@rediffmail.com">mailto:afarhan@rediffmail.com</A>=
]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, January 02, 2001 11:40 PM</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [SIP] a tiny binary sip proxy =
protocol</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>eric wrote -</FONT>
<BR><FONT SIZE=3D2>The idea of a &quot;SIP Lite&quot; sounds =
interesting.&nbsp; However, what benefit do you see by having the =
protocol binary?&nbsp; With shorts and ints, you run into network =
byte-order problems.</FONT></P>

<P><FONT SIZE=3D2>keeping the protocol binary eliminates the need for a =
parser completely. you can directly copy the incoming udp packet into a =
sip lite structure and that is it. this is exceedingly important for =
making sip lite easy to understand.</FONT></P>

<P><FONT SIZE=3D2>the network byte-order will only be a problem for the =
command and the version fields. the ip addresses, ports and session ids =
dont need to arithematically manipulate their bits, so the network byte =
ordering is not a problem.</FONT></P>

<P><FONT SIZE=3D2>- farhan@hotfoon.com</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>_____________________________________________________</FONT>
<BR><FONT SIZE=3D2>Chat with your friends as soon as they come online. =
Get Rediff Bol at</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://bol.rediff.com" =
TARGET=3D"_blank">http://bol.rediff.com</A></FONT>
</P>
<BR>
<BR>
<BR>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>SIP mailing list</FONT>
<BR><FONT SIZE=3D2>SIP@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/sip" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></F=
ONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C075C3.77F52180--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 15:31:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04283
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 15:31:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DE66744344; Wed,  3 Jan 2001 14:32:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id 6631C44338
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 14:31:01 -0500 (EST)
Received: (qmail 11624 invoked by uid 500); 3 Jan 2001 21:13:28 -0000
From: David Frascone <dave@frascone.com>
To: sip@lists.bell-labs.com
Subject: Re: [SIP] a tiny binary sip proxy protocol
Message-ID: <20010103151327.Q10666@newman.frascone.com>
Mail-Followup-To: sip@lists.bell-labs.com
References: <85AA7486A2C1D411BCA20000F8073E43AA5D45@crchy271.us.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <85AA7486A2C1D411BCA20000F8073E43AA5D45@crchy271.us.nortel.com>; from bstucker@nortelnetworks.com on Wed, Jan 03, 2001 at 02:26:35PM -0600
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 15:13:27 -0600

And, don't forget about byte alignment across architectures.  Try to view a
short on a 16 byte boundry on a 64 bit processor that wasn't made by INTEL.

On Wed, Jan 03, 2001 at 02:26:35PM -0600, Brian Stucker wrote:
> Hmm... Some machines use big-endian formats for their bytes, and others
> little-endian. So you still have the problem of which bit of a byte is
> considered most significant.
> 
> Intel uses little-endian, in which the leftmost bit is the least
> significant. Other manufacturers use big-endian in which the rightmost bit
> is the least significant.
> 
> So just copying bits off of a NIC into a struct of some sort, without regard
> to the formatting of those bits, even within a single byte, can be
> problematic.
> 
> Brian
> 
> 
> 
> -----Original Message-----
> From: Ashhar Farhan [mailto:afarhan@rediffmail.com]
> Sent: Tuesday, January 02, 2001 11:40 PM
> Subject: RE: [SIP] a tiny binary sip proxy protocol
> 
> 
> eric wrote -
> The idea of a "SIP Lite" sounds interesting.  However, what benefit do you
> see by having the protocol binary?  With shorts and ints, you run into
> network byte-order problems.
> 
> keeping the protocol binary eliminates the need for a parser completely. you
> can directly copy the incoming udp packet into a sip lite structure and that
> is it. this is exceedingly important for making sip lite easy to understand.
> 
> the network byte-order will only be a problem for the command and the
> version fields. the ip addresses, ports and session ids dont need to
> arithematically manipulate their bits, so the network byte ordering is not a
> problem.
> 
> - farhan@hotfoon.com
> 
> 
> _____________________________________________________
> Chat with your friends as soon as they come online. Get Rediff Bol at
> http://bol.rediff.com
> 
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 15:33:17 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04301
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 15:33:17 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5946944373; Wed,  3 Jan 2001 14:32:08 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by lists.bell-labs.com (Postfix) with ESMTP id D6DD844338
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 14:31:32 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05950;
	Wed, 3 Jan 2001 12:31:15 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA11108;
	Wed, 3 Jan 2001 12:31:14 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA19579;
	Wed, 3 Jan 2001 12:31:08 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
To: Michael Thomas <mat@cisco.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        Stephen Thomas <stephen.thomas@transnexus.com>,
        SIP List <sip@lists.bell-labs.com>
In-Reply-To: "Your message with ID" <14931.25708.455779.464579@thomasm-u1.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.978553658.6342.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 12:27:38 -0800 (PST)

>    The problem is that you're proposing to
>    backhaul most (all?) of the SIP message 
>    back as an opaque blob. That sort of begs
>    the question of why don't you just send it
>    as a SIP message as Henning suggests; the
>    AAA is, if nothing else, going to have quite
>    a bit of proxy logic to determine whether
>    it should authorize the request. Looks like
>    duck, walks like duck... probably is duck.

I *assume* that you understand how RADIUS and/or DIAMETER works. The NAS pulls
specific items out of the request (SIP message), and inserts them into what we
commonly call AVPs (or attribute value pairs). The AAA server takes this
information to make its authorization decision. The only reason why the SIP
request is sent at all is for authentication reasons, since the SIP server
doesn't have the mobile's long term secret.

> 
>  > In fact, the
>  > following was done: 1. Allow the mobile to have an NAI as its identifier,
> as
>  > opposed to a home address (something that is already supported in SIP, so
> no
>  > change required). 2. Allow the mobile to share a secret with its AAAH, as
>  > opposed to its Home Agent (something that is VERY easy to do, and probably
>  > requires NO protocol changes in SIP).
> 
>    I assume that you're talking about
>    draft-ietf-mobileip-aaa-key-01.txt?
yes.

>    Assuming that I'm
>    reading the draft correctly, I have to tell you that the
>    entire idea makes me extremely queasy: shipping the user's
>    long term key from the AAA to other entities of
>    which have questionable and/or unknown security
>    practices seems *extremely* dangerous.

Perhaps a re-read is in order? In fact, perhaps section 6.0 of
draft-calhoun-diameter-mobileip-11.txt would be a better read.
draft-ietf-mobileip-aaa-key-01.txt carries the ephemeral keys created in the
former document.

(btw, I'll try not to take offense that you would even think that I would be
passing around a mobile's long term secret to other network entities).

> 
>    Kerberos, for this very reason, does not do this; instead
>    a short term ephemeral secret is created for use between
>    the client and server. That you even call the AAAH
>    a "KDC" (to which I don't disagree) should give pause
>    that the AAA should at least learn the lessons of "real"
>    KDC's which consumes endless hours of lots of
>    smart security folks. FYI, I'm in the process
>    of writing a draft which has the functionality
>    you're looking for but uses Kerberos mechanisms 
>    to create an ephemeral session key. 

Thanks for the Kerberos tutorial :)

Seriously, this is precisely what the AAAH does.

PatC


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 15:35:06 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04351
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 15:35:06 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AF00044375; Wed,  3 Jan 2001 14:33:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id 6D3AB44375
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 14:32:09 -0500 (EST)
Received: (qmail 11642 invoked by uid 500); 3 Jan 2001 21:14:34 -0000
From: David Frascone <dave@frascone.com>
To: sip@lists.bell-labs.com
Subject: Re: [SIP] a tiny binary sip proxy protocol
Message-ID: <20010103151434.R10666@newman.frascone.com>
Mail-Followup-To: sip@lists.bell-labs.com
References: <85AA7486A2C1D411BCA20000F8073E43AA5D45@crchy271.us.nortel.com> <20010103151327.Q10666@newman.frascone.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010103151327.Q10666@newman.frascone.com>; from dave@frascone.com on Wed, Jan 03, 2001 at 03:13:27PM -0600
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 15:14:34 -0600


Err "16 byte" -> "16 bit". -- Sorry

On Wed, Jan 03, 2001 at 03:13:27PM -0600, David Frascone wrote:
> And, don't forget about byte alignment across architectures.  Try to view a
> short on a 16 byte boundry on a 64 bit processor that wasn't made by INTEL.
> 
> On Wed, Jan 03, 2001 at 02:26:35PM -0600, Brian Stucker wrote:
> > Hmm... Some machines use big-endian formats for their bytes, and others
> > little-endian. So you still have the problem of which bit of a byte is
> > considered most significant.
> > 
> > Intel uses little-endian, in which the leftmost bit is the least
> > significant. Other manufacturers use big-endian in which the rightmost bit
> > is the least significant.
> > 
> > So just copying bits off of a NIC into a struct of some sort, without regard
> > to the formatting of those bits, even within a single byte, can be
> > problematic.
> > 
> > Brian
> > 
> > 
> > 
> > -----Original Message-----
> > From: Ashhar Farhan [mailto:afarhan@rediffmail.com]
> > Sent: Tuesday, January 02, 2001 11:40 PM
> > Subject: RE: [SIP] a tiny binary sip proxy protocol
> > 
> > 
> > eric wrote -
> > The idea of a "SIP Lite" sounds interesting.  However, what benefit do you
> > see by having the protocol binary?  With shorts and ints, you run into
> > network byte-order problems.
> > 
> > keeping the protocol binary eliminates the need for a parser completely. you
> > can directly copy the incoming udp packet into a sip lite structure and that
> > is it. this is exceedingly important for making sip lite easy to understand.
> > 
> > the network byte-order will only be a problem for the command and the
> > version fields. the ip addresses, ports and session ids dont need to
> > arithematically manipulate their bits, so the network byte ordering is not a
> > problem.
> > 
> > - farhan@hotfoon.com
> > 
> > 
> > _____________________________________________________
> > Chat with your friends as soon as they come online. Get Rediff Bol at
> > http://bol.rediff.com
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 15:38:02 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04494
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 15:38:02 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AF7CF44375; Wed,  3 Jan 2001 14:36:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id 76B9044373
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 14:35:09 -0500 (EST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21220;
	Wed, 3 Jan 2001 12:34:56 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA11711;
	Wed, 3 Jan 2001 12:34:56 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA19788;
	Wed, 3 Jan 2001 12:34:55 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
To: "Gross, Gerhard" <gerhard.gross@intel.com>
Cc: SIP List <sip@lists.bell-labs.com>
In-Reply-To: "Your message with ID" <4148FEAAD879D311AC5700A0C969E8902D4908@orsmsx35.jf.intel.com>
Message-ID: <Roam.SIMC.2.0.6.978553885.6700.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 12:31:25 -0800 (PST)

> > In an end-to-end world, we should aim primarily
> > for public-key certicates, not Radius like checks.
> 
> As discussed in
> http://search.ietf.org/internet-drafts/draft-gross-sipaq-00.txt

Just for the record, DIAMETER *does* allow public key authentication.

PatC


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 15:41:41 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04610
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 15:41:40 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B13E944380; Wed,  3 Jan 2001 14:37:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by lists.bell-labs.com (Postfix) with ESMTP id B17544437F
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 14:36:54 -0500 (EST)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch2.nortel.com; Wed, 3 Jan 2001 14:30:37 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <Z8FFQQPZ>; Wed, 3 Jan 2001 14:35:13 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43AA5D67@crchy271.us.nortel.com>
From: "Brian Stucker" <bstucker@nortelnetworks.com>
To: David Frascone <dave@frascone.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] a tiny binary sip proxy protocol
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C075C4.A84926A0"
X-Orig: <bstucker@americasm01.nt.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 14:35:06 -0600

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_01C075C4.A84926A0
Content-Type: text/plain;
	charset="iso-8859-1"

True. It's amazing how much hton, ntoh, and the MS MFC classes do for you
when you really look at what's going on.

Brian

-----Original Message-----
From: David Frascone [mailto:dave@frascone.com]
Sent: Wednesday, January 03, 2001 3:13 PM
To: sip@lists.bell-labs.com
Subject: Re: [SIP] a tiny binary sip proxy protocol


And, don't forget about byte alignment across architectures.  Try to view a
short on a 16 byte boundry on a 64 bit processor that wasn't made by INTEL.

On Wed, Jan 03, 2001 at 02:26:35PM -0600, Brian Stucker wrote:
> Hmm... Some machines use big-endian formats for their bytes, and others
> little-endian. So you still have the problem of which bit of a byte is
> considered most significant.
> 
> Intel uses little-endian, in which the leftmost bit is the least
> significant. Other manufacturers use big-endian in which the rightmost bit
> is the least significant.
> 
> So just copying bits off of a NIC into a struct of some sort, without
regard
> to the formatting of those bits, even within a single byte, can be
> problematic.
> 
> Brian
> 
> 
> 
> -----Original Message-----
> From: Ashhar Farhan [mailto:afarhan@rediffmail.com]
> Sent: Tuesday, January 02, 2001 11:40 PM
> Subject: RE: [SIP] a tiny binary sip proxy protocol
> 
> 
> eric wrote -
> The idea of a "SIP Lite" sounds interesting.  However, what benefit do you
> see by having the protocol binary?  With shorts and ints, you run into
> network byte-order problems.
> 
> keeping the protocol binary eliminates the need for a parser completely.
you
> can directly copy the incoming udp packet into a sip lite structure and
that
> is it. this is exceedingly important for making sip lite easy to
understand.
> 
> the network byte-order will only be a problem for the command and the
> version fields. the ip addresses, ports and session ids dont need to
> arithematically manipulate their bits, so the network byte ordering is not
a
> problem.
> 
> - farhan@hotfoon.com
> 
> 
> _____________________________________________________
> Chat with your friends as soon as they come online. Get Rediff Bol at
> http://bol.rediff.com
> 
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C075C4.A84926A0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: [SIP] a tiny binary sip proxy protocol</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>True. It's amazing how much hton, ntoh, and the MS MFC classes do for you when you really look at what's going on.</FONT>
</P>

<P><FONT SIZE=2>Brian</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: David Frascone [<A HREF="mailto:dave@frascone.com">mailto:dave@frascone.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Wednesday, January 03, 2001 3:13 PM</FONT>
<BR><FONT SIZE=2>To: sip@lists.bell-labs.com</FONT>
<BR><FONT SIZE=2>Subject: Re: [SIP] a tiny binary sip proxy protocol</FONT>
</P>
<BR>

<P><FONT SIZE=2>And, don't forget about byte alignment across architectures.&nbsp; Try to view a</FONT>
<BR><FONT SIZE=2>short on a 16 byte boundry on a 64 bit processor that wasn't made by INTEL.</FONT>
</P>

<P><FONT SIZE=2>On Wed, Jan 03, 2001 at 02:26:35PM -0600, Brian Stucker wrote:</FONT>
<BR><FONT SIZE=2>&gt; Hmm... Some machines use big-endian formats for their bytes, and others</FONT>
<BR><FONT SIZE=2>&gt; little-endian. So you still have the problem of which bit of a byte is</FONT>
<BR><FONT SIZE=2>&gt; considered most significant.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Intel uses little-endian, in which the leftmost bit is the least</FONT>
<BR><FONT SIZE=2>&gt; significant. Other manufacturers use big-endian in which the rightmost bit</FONT>
<BR><FONT SIZE=2>&gt; is the least significant.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; So just copying bits off of a NIC into a struct of some sort, without regard</FONT>
<BR><FONT SIZE=2>&gt; to the formatting of those bits, even within a single byte, can be</FONT>
<BR><FONT SIZE=2>&gt; problematic.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Brian</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Ashhar Farhan [<A HREF="mailto:afarhan@rediffmail.com">mailto:afarhan@rediffmail.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Tuesday, January 02, 2001 11:40 PM</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [SIP] a tiny binary sip proxy protocol</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; eric wrote -</FONT>
<BR><FONT SIZE=2>&gt; The idea of a &quot;SIP Lite&quot; sounds interesting.&nbsp; However, what benefit do you</FONT>
<BR><FONT SIZE=2>&gt; see by having the protocol binary?&nbsp; With shorts and ints, you run into</FONT>
<BR><FONT SIZE=2>&gt; network byte-order problems.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; keeping the protocol binary eliminates the need for a parser completely. you</FONT>
<BR><FONT SIZE=2>&gt; can directly copy the incoming udp packet into a sip lite structure and that</FONT>
<BR><FONT SIZE=2>&gt; is it. this is exceedingly important for making sip lite easy to understand.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; the network byte-order will only be a problem for the command and the</FONT>
<BR><FONT SIZE=2>&gt; version fields. the ip addresses, ports and session ids dont need to</FONT>
<BR><FONT SIZE=2>&gt; arithematically manipulate their bits, so the network byte ordering is not a</FONT>
<BR><FONT SIZE=2>&gt; problem.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; - farhan@hotfoon.com</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _____________________________________________________</FONT>
<BR><FONT SIZE=2>&gt; Chat with your friends as soon as they come online. Get Rediff Bol at</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="http://bol.rediff.com" TARGET="_blank">http://bol.rediff.com</A></FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; _______________________________________________</FONT>
<BR><FONT SIZE=2>&gt; SIP mailing list</FONT>
<BR><FONT SIZE=2>&gt; SIP@lists.bell-labs.com</FONT>
<BR><FONT SIZE=2>&gt; <A HREF="http://lists.bell-labs.com/mailman/listinfo/sip" TARGET="_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></FONT>
</P>

<P><FONT SIZE=2>_______________________________________________</FONT>
<BR><FONT SIZE=2>SIP mailing list</FONT>
<BR><FONT SIZE=2>SIP@lists.bell-labs.com</FONT>
<BR><FONT SIZE=2><A HREF="http://lists.bell-labs.com/mailman/listinfo/sip" TARGET="_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C075C4.A84926A0--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 15:57:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04812
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 15:57:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F0E3B4435A; Wed,  3 Jan 2001 14:55:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by lists.bell-labs.com (Postfix) with ESMTP id 9B56B44339
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 14:54:41 -0500 (EST)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch1.nortel.com; Wed, 3 Jan 2001 14:53:47 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <Z8FFQRJK>; Wed, 3 Jan 2001 14:53:41 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43AA5D9F@crchy271.us.nortel.com>
From: "Brian Stucker" <bstucker@nortelnetworks.com>
To: Dean Willis <dean.willis@softarmor.com>,
        David Frascone <dave@frascone.com>,
        "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
Subject: RE: [SIP] Discussion of Default Timers
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C075C7.3EF0BD00"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 14:53:38 -0600

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_01C075C7.3EF0BD00
Content-Type: text/plain;
	charset="iso-8859-1"

Has there been any consideration or thought to introducing network
selectable timers?

Just off the top of my head, but it seems that it wouldn't be too difficult
to just TELL the UA how long their timers should be on a per call basis. For
instance, if you send an INVITE to your local SIP proxy, the proxy could
send back appropriately estimated timers for that call that the UA then uses
for the duration of that context.

That way, you have a default setting specified in the RFC, and if the proxy
knows that you're likely to unnecessarily retransmit (maybe it's been
datafilled to know that some outbound routes take a long time to process, or
that network traffic is high right then) it can direct the UA to fine-tune
it's timers to use when signalling to the proxy for THAT call context.

Also, and I don't know where everyone's expertise lies, so I may be
preaching to the choir here, please keep in mind tremendous latentcies
involved in wireless applications (and I'm not talking wireless ethernet
either, I'm talking cellular). There is no way any packet is going to get to
a cell phone or other cellular device in even remotely the latentcy figures
I've seen discussed on here. If you can transmit a packet from a SIP proxy
to a SIP UA sitting on a PDA or cell phone in 10ms you'd be internationally
famous. It might take several hundred ms just to get a raw UDP packet from
the edge of a wireless data network out to the mobile station under some
standards.

In that context, I would recommend longer timers, but for a LAN situation
that could degrade performance, which is why I bring up sending the timers
appropriate for that network scenario up.

If I know I'm calling Poland from Dallas, I also know to expect a longer
than normal time that I'll have to wait for the call to go through. If I'm
calling someone at their desk down the hall, I'm not going to wait as long.

Thoughts?

Brian

-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Sent: Tuesday, January 02, 2001 12:36 PM
To: David Frascone; IETF SIP (E-mail)
Subject: Re: [SIP] Discussion of Default Timers



Well, those are the rough rules of thumb we used in network design just a
few years ago. Routers often perform much better these days -- assuming you
don't hit head of line blocking, small pipe serialization delay, an OSPF MST
recalc, a sluggish store-and-forward firewall,  congested MAE, or some other
annoyance  en-route. 10ms per router does represent a useful outer bound for
planning purposes. 3ms is probably closer to mean.

And the particular destination you listed www.hackersquest.gomp.ch is
hanging right off the uunet backbone -- 180 ms from my uunet-connected
router. There are worse routes.

But in any case, I have seen trial deployments where large numbers of T1
expirations occur.

Even if network transit time is only 180ms, a couple of proxies in between
can still easily push us over 500ms.

--
Dean

----- Original Message -----
From: "David Frascone" <dave@frascone.com>
To: "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
Sent: Tuesday, January 02, 2001 12:49 PM
Subject: Re: [SIP] Discussion of Default Timers


> Hmmm, I think your router lag is a bit off.  Doing a ping from Dallas, TX
to
> somewhere in China (www.hackersquest.gomp.ch) yeilds ~160ms round trip
time.
>
> And, I'm 24 hops from there.  24 * 10ms would be 240 ms of router lag
alone.
>
> So, I think your calculations are a bit off.
>
> On Tue, Jan 02, 2001 at 11:26:09AM -0600, Dean Willis wrote:
> >
> > I've started to wonder about the retransmission timers recommended in
2543.
> >
> > The basic assumption is that VoIP networks will have round-trip times of
> > less than 500ms. This seems to be a valid assumptio for the medai path,
but
> > remember -- with SIP, the SIGNALING path is not necessarily thesame as
the
> > MEDIA path. And the timers apply to the SIGNALING path.
> >
> > Many of the architectures I'm seeing have three thousand kilometers, ten
> > routers, and six proxies between two SIP endpoints.  Assuming
6ms/1000km,
> > 10ms/router, and 50ms/proxy, that works out to 418ms each way, or a
total of
> > 836ms round trip. With default settings, the originating UA is going to
> > resend its INVITE after only 500ms unless response is received.
Everybody
> > wants to use stateless proxies for performance reaons. So, nearly every
> > INVITE gets sent twice. This can be severely detrimental to the function
of
> > a proxy that is operating at near peak capacity -- in fact, it basically
> > cuts the peak capacity of a proxy in half whenever proxy chains are
> > configured in such a way that T1 is regularly exceeded.
> >
> > There are a couple of alternatives that come to mind:
> >
> > 1) Deploy faster proxies.
> > 2) Deploy 100-generating proxies at all levels to prevent timer
expiration
> > due to downstream latency.
> > 3) Change the default timers.
> >
> > Thoughts?
> >
> > --
> > Dean Willis
> >
> >
> >
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C075C7.3EF0BD00
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [SIP] Discussion of Default Timers</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Has there been any consideration or thought to =
introducing network selectable timers?</FONT>
</P>

<P><FONT SIZE=3D2>Just off the top of my head, but it seems that it =
wouldn't be too difficult to just TELL the UA how long their timers =
should be on a per call basis. For instance, if you send an INVITE to =
your local SIP proxy, the proxy could send back appropriately estimated =
timers for that call that the UA then uses for the duration of that =
context.</FONT></P>

<P><FONT SIZE=3D2>That way, you have a default setting specified in the =
RFC, and if the proxy knows that you're likely to unnecessarily =
retransmit (maybe it's been datafilled to know that some outbound =
routes take a long time to process, or that network traffic is high =
right then) it can direct the UA to fine-tune it's timers to use when =
signalling to the proxy for THAT call context.</FONT></P>

<P><FONT SIZE=3D2>Also, and I don't know where everyone's expertise =
lies, so I may be preaching to the choir here, please keep in mind =
tremendous latentcies involved in wireless applications (and I'm not =
talking wireless ethernet either, I'm talking cellular). There is no =
way any packet is going to get to a cell phone or other cellular device =
in even remotely the latentcy figures I've seen discussed on here. If =
you can transmit a packet from a SIP proxy to a SIP UA sitting on a PDA =
or cell phone in 10ms you'd be internationally famous. It might take =
several hundred ms just to get a raw UDP packet from the edge of a =
wireless data network out to the mobile station under some =
standards.</FONT></P>

<P><FONT SIZE=3D2>In that context, I would recommend longer timers, but =
for a LAN situation that could degrade performance, which is why I =
bring up sending the timers appropriate for that network scenario =
up.</FONT></P>

<P><FONT SIZE=3D2>If I know I'm calling Poland from Dallas, I also know =
to expect a longer than normal time that I'll have to wait for the call =
to go through. If I'm calling someone at their desk down the hall, I'm =
not going to wait as long.</FONT></P>

<P><FONT SIZE=3D2>Thoughts?</FONT>
</P>

<P><FONT SIZE=3D2>Brian</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Dean Willis [<A =
HREF=3D"mailto:dean.willis@softarmor.com">mailto:dean.willis@softarmor.c=
om</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, January 02, 2001 12:36 PM</FONT>
<BR><FONT SIZE=3D2>To: David Frascone; IETF SIP (E-mail)</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [SIP] Discussion of Default =
Timers</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Well, those are the rough rules of thumb we used in =
network design just a</FONT>
<BR><FONT SIZE=3D2>few years ago. Routers often perform much better =
these days -- assuming you</FONT>
<BR><FONT SIZE=3D2>don't hit head of line blocking, small pipe =
serialization delay, an OSPF MST</FONT>
<BR><FONT SIZE=3D2>recalc, a sluggish store-and-forward firewall,&nbsp; =
congested MAE, or some other</FONT>
<BR><FONT SIZE=3D2>annoyance&nbsp; en-route. 10ms per router does =
represent a useful outer bound for</FONT>
<BR><FONT SIZE=3D2>planning purposes. 3ms is probably closer to =
mean.</FONT>
</P>

<P><FONT SIZE=3D2>And the particular destination you listed =
www.hackersquest.gomp.ch is</FONT>
<BR><FONT SIZE=3D2>hanging right off the uunet backbone -- 180 ms from =
my uunet-connected</FONT>
<BR><FONT SIZE=3D2>router. There are worse routes.</FONT>
</P>

<P><FONT SIZE=3D2>But in any case, I have seen trial deployments where =
large numbers of T1</FONT>
<BR><FONT SIZE=3D2>expirations occur.</FONT>
</P>

<P><FONT SIZE=3D2>Even if network transit time is only 180ms, a couple =
of proxies in between</FONT>
<BR><FONT SIZE=3D2>can still easily push us over 500ms.</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>Dean</FONT>
</P>

<P><FONT SIZE=3D2>----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>From: &quot;David Frascone&quot; =
&lt;dave@frascone.com&gt;</FONT>
<BR><FONT SIZE=3D2>To: &quot;IETF SIP (E-mail)&quot; =
&lt;sip@lists.bell-labs.com&gt;</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, January 02, 2001 12:49 PM</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [SIP] Discussion of Default =
Timers</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; Hmmm, I think your router lag is a bit =
off.&nbsp; Doing a ping from Dallas, TX</FONT>
<BR><FONT SIZE=3D2>to</FONT>
<BR><FONT SIZE=3D2>&gt; somewhere in China (www.hackersquest.gomp.ch) =
yeilds ~160ms round trip</FONT>
<BR><FONT SIZE=3D2>time.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; And, I'm 24 hops from there.&nbsp; 24 * 10ms =
would be 240 ms of router lag</FONT>
<BR><FONT SIZE=3D2>alone.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; So, I think your calculations are a bit =
off.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; On Tue, Jan 02, 2001 at 11:26:09AM -0600, Dean =
Willis wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I've started to wonder about the =
retransmission timers recommended in</FONT>
<BR><FONT SIZE=3D2>2543.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The basic assumption is that VoIP networks =
will have round-trip times of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; less than 500ms. This seems to be a valid =
assumptio for the medai path,</FONT>
<BR><FONT SIZE=3D2>but</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; remember -- with SIP, the SIGNALING path =
is not necessarily thesame as</FONT>
<BR><FONT SIZE=3D2>the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; MEDIA path. And the timers apply to the =
SIGNALING path.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Many of the architectures I'm seeing have =
three thousand kilometers, ten</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; routers, and six proxies between two SIP =
endpoints.&nbsp; Assuming</FONT>
<BR><FONT SIZE=3D2>6ms/1000km,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 10ms/router, and 50ms/proxy, that works =
out to 418ms each way, or a</FONT>
<BR><FONT SIZE=3D2>total of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 836ms round trip. With default settings, =
the originating UA is going to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; resend its INVITE after only 500ms unless =
response is received.</FONT>
<BR><FONT SIZE=3D2>Everybody</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; wants to use stateless proxies for =
performance reaons. So, nearly every</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; INVITE gets sent twice. This can be =
severely detrimental to the function</FONT>
<BR><FONT SIZE=3D2>of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; a proxy that is operating at near peak =
capacity -- in fact, it basically</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; cuts the peak capacity of a proxy in half =
whenever proxy chains are</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; configured in such a way that T1 is =
regularly exceeded.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; There are a couple of alternatives that =
come to mind:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 1) Deploy faster proxies.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 2) Deploy 100-generating proxies at all =
levels to prevent timer</FONT>
<BR><FONT SIZE=3D2>expiration</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; due to downstream latency.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 3) Change the default timers.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Thoughts?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Dean Willis</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; SIP mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; SIP@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/sip" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></F=
ONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; SIP mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; SIP@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/sip" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></F=
ONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>SIP mailing list</FONT>
<BR><FONT SIZE=3D2>SIP@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/sip" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></F=
ONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C075C7.3EF0BD00--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 16:04:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04964
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 16:04:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 82A454436D; Wed,  3 Jan 2001 15:05:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 002E544362
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 15:04:23 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA27221;
	Wed, 3 Jan 2001 16:04:11 -0500 (EST)
Message-ID: <3A5393CB.9B23DDF@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Gross, Gerhard" <gerhard.gross@intel.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
References: <4148FEAAD879D311AC5700A0C969E8902D490A@orsmsx35.jf.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 03 Jan 2001 16:04:11 -0500
Content-Transfer-Encoding: 7bit

"Gross, Gerhard" wrote:
> 
> >Instead of re-casting the SIP request into another format and
> >translating status codes between protocols, why not just proxy the SIP
> >request to whatever database/server decides whether the person has
> >subscribed to this service?
> 
> One reason is for simplicity and to potentially
> increase processing speed. This is done by taking
> advantage of the SIP parser already built into
> the SIP proxy. If the whole SIP message were
> just forwarded as is to the PDP (policy decision
> point), the PDP would need some sort of SIP
> parser (thus adding complexity/redundancy to
> the chain).

This assumes that SIP parsing is a major delay or processing expense.
Experience seems to indicate that it is not, compared to the typical
database lookups, crypto and other operations that need to take place.

> 
> On the other hand, while the SIP proxy parses the
> SIP message, it may extract certain information
> from it and put it in a simpler and smaller structure
> to be passed on to the PDP (AAA/policy server). Such
> a structure/protocol has been defined in
> http://search.ietf.org/internet-drafts/draft-gross-cops-sip-00.txt.
> 

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 16:09:30 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05014
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 16:09:29 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 00CFC4439A; Wed,  3 Jan 2001 15:08:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 75F4C44344
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 15:07:38 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA27483;
	Wed, 3 Jan 2001 16:07:22 -0500 (EST)
Message-ID: <3A53948A.BB561240@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Brian Stucker <bstucker@nortelnetworks.com>
Cc: Ashhar Farhan <afarhan@rediffmail.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] a tiny binary sip proxy protocol
References: <85AA7486A2C1D411BCA20000F8073E43AA5D45@crchy271.us.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 03 Jan 2001 16:07:22 -0500
Content-Transfer-Encoding: 7bit

Thanks for solving a non-problem (parsing expense). Can we move on to
other, more pressing concerns?
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 16:52:36 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05850
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 16:52:35 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8D3B044337; Wed,  3 Jan 2001 15:51:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by lists.bell-labs.com (Postfix) with ESMTP id 4194144336
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 15:50:20 -0500 (EST)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch2.nortel.com; Wed, 3 Jan 2001 15:42:46 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <Z8FFQTW2>; Wed, 3 Jan 2001 15:47:22 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43AA5E48@crchy271.us.nortel.com>
From: "Brian Stucker" <bstucker@nortelnetworks.com>
To: Sean Olson <sean.olson@ericsson.com>,
        Dean Willis <dean.willis@softarmor.com>
Cc: "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
Subject: RE: [SIP] Discussion of Default Timers
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C075CE.BE893630"
X-Orig: <bstucker@americasm01.nt.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 15:47:18 -0600

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_01C075CE.BE893630
Content-Type: text/plain;
	charset="iso-8859-1"

Ah... Should have read further back into the thread than I did.

If I read 2543 correctly, it already allows for timers on the clients to be
autonomously extended (but not shortened) by the client without any server
interaction.

I guess I would recommend that we consider adding the following (along the
lines of the retry-after header):

----<snippet start>----

response-header ...
                | Context-Timers


Header field              where       proxy ACK BYE CAN INV OPT REG
-------------------------------------------------------------------
Context-Timers           100,18x        -    -   -   -   o   -   o


Context-Timers

The Context-Timers response-header field MAY be included to RECOMMEND to a
client or server on a per-hop, per context basis, to use timer values
different than the default SIP values on a 1xx response from an INVITE.
These timers would then be considered to be in effect for the remainder of
that call context. The remaining time left of any pending timers upon
processing the response would be deducted from the values specified in the
response, and the timers updated with the result.

Additionally, this response-header MAY also be included as part of a final
200 response to a REGISTER in order to update the timer lengths
semi-permanently over all call contexts for that registration period. Timers
received in 1xx class responses take precendence over those received in
response to a registration.

Context-Timers = "Context-Timers" ":" (( 1# (Timer-name "=" length) )
*(";"))

timer-name = RFC defined timer string
length = timer interval in ms.

Example:

Context-Timers: T1=800;T2=1200

Would update timers T1 and T2 to 800ms, and 1200ms, respectively. Note, that
if the length of the timer specified is SHORTER than the default minimums
specified in the RFC, that the value is discarded and ignored.



----<snippet end>----

Start throwing darts... I would think this sort of arrangement would keep
everyone happy by letting them have their proxies tell the subtending UAs
whatever values are appropriate to use in that network at that moment
(perhaps even for that particular call). For instance, if the proxy knows
that it's slow, or that it's going to have to go off and do something
special with this request, it can tell the UA to hold on a bit longer than
normal. If the network architecture itself is slower (wireless access) then
it can tell UAs who might have migrated from a LAN connection that they need
to give the system a bit more time to do things now, etc...

Again, off the top of my head, so if there's errors in the syntax or
reasoning, I'm not surprised. Just throwing something out there for
consideration.

Brian Stucker
Nortel Networks



-----Original Message-----
From: Sean Olson [mailto:sean.olson@ericsson.com]
Sent: Tuesday, January 02, 2001 11:55 AM
To: Dean Willis
Cc: IETF SIP (E-mail)
Subject: Re: [SIP] Discussion of Default Timers


I agree that this is a problem and it is aggravated in the
case of wireless access where latencies are even larger.

Regarding the alternatives you list:

1) Faster proxies -- this is basically chasing rainbows. The processing
   delay can only be cut down so much and it is prone to break when
   new topologies introduce additional proxies

2) More statefull proxies -- This seems like a reasonable approach
   for many deployments (enterprise and GSTN gateways in particular)
   but of course can't be fixed by standardization, i.e. we can't
   mandate this (at least in the SIP spec)

3) Changing the default timers -- I like this approach but I think
   it isn't realistic given the current implementations. How many
   implementations hard-code this value I wonder?

I would recommend a combination of alternatives 2 and 3 for 
most architectures. Perhaps this could be part of a larger set
of recommendations in a BCP?

/sean

Dean Willis wrote:
> 
> I've started to wonder about the retransmission timers recommended in
2543.
> 
> The basic assumption is that VoIP networks will have round-trip times of
> less than 500ms. This seems to be a valid assumptio for the medai path,
but
> remember -- with SIP, the SIGNALING path is not necessarily thesame as the
> MEDIA path. And the timers apply to the SIGNALING path.
> 
> Many of the architectures I'm seeing have three thousand kilometers, ten
> routers, and six proxies between two SIP endpoints.  Assuming 6ms/1000km,
> 10ms/router, and 50ms/proxy, that works out to 418ms each way, or a total
of
> 836ms round trip. With default settings, the originating UA is going to
> resend its INVITE after only 500ms unless response is received. Everybody
> wants to use stateless proxies for performance reaons. So, nearly every
> INVITE gets sent twice. This can be severely detrimental to the function
of
> a proxy that is operating at near peak capacity -- in fact, it basically
> cuts the peak capacity of a proxy in half whenever proxy chains are
> configured in such a way that T1 is regularly exceeded.
> 
> There are a couple of alternatives that come to mind:
> 
> 1) Deploy faster proxies.
> 2) Deploy 100-generating proxies at all levels to prevent timer expiration
> due to downstream latency.
> 3) Change the default timers.
> 
> Thoughts?
> 
> --
> Dean Willis
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C075CE.BE893630
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [SIP] Discussion of Default Timers</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Ah... Should have read further back into the thread =
than I did.</FONT>
</P>

<P><FONT SIZE=3D2>If I read 2543 correctly, it already allows for =
timers on the clients to be autonomously extended (but not shortened) =
by the client without any server interaction.</FONT></P>

<P><FONT SIZE=3D2>I guess I would recommend that we consider adding the =
following (along the lines of the retry-after header):</FONT>
</P>

<P><FONT SIZE=3D2>----&lt;snippet start&gt;----</FONT>
</P>

<P><FONT SIZE=3D2>response-header ...</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp; | Context-Timers</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Header =
field&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; where&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; proxy ACK BYE CAN =
INV OPT REG</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
----</FONT>
<BR><FONT =
SIZE=3D2>Context-Timers&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; 100,18x&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
-&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp; =
o&nbsp;&nbsp; -&nbsp;&nbsp; o</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Context-Timers</FONT>
</P>

<P><FONT SIZE=3D2>The Context-Timers response-header field MAY be =
included to RECOMMEND to a client or server on a per-hop, per context =
basis, to use timer values different than the default SIP values on a =
1xx response from an INVITE. These timers would then be considered to =
be in effect for the remainder of that call context. The remaining time =
left of any pending timers upon processing the response would be =
deducted from the values specified in the response, and the timers =
updated with the result.</FONT></P>

<P><FONT SIZE=3D2>Additionally, this response-header MAY also be =
included as part of a final 200 response to a REGISTER in order to =
update the timer lengths semi-permanently over all call contexts for =
that registration period. Timers received in 1xx class responses take =
precendence over those received in response to a =
registration.</FONT></P>

<P><FONT SIZE=3D2>Context-Timers =3D &quot;Context-Timers&quot; =
&quot;:&quot; (( 1# (Timer-name &quot;=3D&quot; length) ) =
*(&quot;;&quot;))</FONT>
</P>

<P><FONT SIZE=3D2>timer-name =3D RFC defined timer string</FONT>
<BR><FONT SIZE=3D2>length =3D timer interval in ms.</FONT>
</P>

<P><FONT SIZE=3D2>Example:</FONT>
</P>

<P><FONT SIZE=3D2>Context-Timers: T1=3D800;T2=3D1200</FONT>
</P>

<P><FONT SIZE=3D2>Would update timers T1 and T2 to 800ms, and 1200ms, =
respectively. Note, that if the length of the timer specified is =
SHORTER than the default minimums specified in the RFC, that the value =
is discarded and ignored.</FONT></P>
<BR>
<BR>

<P><FONT SIZE=3D2>----&lt;snippet end&gt;----</FONT>
</P>

<P><FONT SIZE=3D2>Start throwing darts... I would think this sort of =
arrangement would keep everyone happy by letting them have their =
proxies tell the subtending UAs whatever values are appropriate to use =
in that network at that moment (perhaps even for that particular call). =
For instance, if the proxy knows that it's slow, or that it's going to =
have to go off and do something special with this request, it can tell =
the UA to hold on a bit longer than normal. If the network architecture =
itself is slower (wireless access) then it can tell UAs who might have =
migrated from a LAN connection that they need to give the system a bit =
more time to do things now, etc...</FONT></P>

<P><FONT SIZE=3D2>Again, off the top of my head, so if there's errors =
in the syntax or reasoning, I'm not surprised. Just throwing something =
out there for consideration.</FONT></P>

<P><FONT SIZE=3D2>Brian Stucker</FONT>
<BR><FONT SIZE=3D2>Nortel Networks</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Sean Olson [<A =
HREF=3D"mailto:sean.olson@ericsson.com">mailto:sean.olson@ericsson.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, January 02, 2001 11:55 AM</FONT>
<BR><FONT SIZE=3D2>To: Dean Willis</FONT>
<BR><FONT SIZE=3D2>Cc: IETF SIP (E-mail)</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [SIP] Discussion of Default =
Timers</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I agree that this is a problem and it is aggravated =
in the</FONT>
<BR><FONT SIZE=3D2>case of wireless access where latencies are even =
larger.</FONT>
</P>

<P><FONT SIZE=3D2>Regarding the alternatives you list:</FONT>
</P>

<P><FONT SIZE=3D2>1) Faster proxies -- this is basically chasing =
rainbows. The processing</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; delay can only be cut down so much and =
it is prone to break when</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; new topologies introduce additional =
proxies</FONT>
</P>

<P><FONT SIZE=3D2>2) More statefull proxies -- This seems like a =
reasonable approach</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; for many deployments (enterprise and =
GSTN gateways in particular)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; but of course can't be fixed by =
standardization, i.e. we can't</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; mandate this (at least in the SIP =
spec)</FONT>
</P>

<P><FONT SIZE=3D2>3) Changing the default timers -- I like this =
approach but I think</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; it isn't realistic given the current =
implementations. How many</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; implementations hard-code this value I =
wonder?</FONT>
</P>

<P><FONT SIZE=3D2>I would recommend a combination of alternatives 2 and =
3 for </FONT>
<BR><FONT SIZE=3D2>most architectures. Perhaps this could be part of a =
larger set</FONT>
<BR><FONT SIZE=3D2>of recommendations in a BCP?</FONT>
</P>

<P><FONT SIZE=3D2>/sean</FONT>
</P>

<P><FONT SIZE=3D2>Dean Willis wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I've started to wonder about the retransmission =
timers recommended in 2543.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The basic assumption is that VoIP networks will =
have round-trip times of</FONT>
<BR><FONT SIZE=3D2>&gt; less than 500ms. This seems to be a valid =
assumptio for the medai path, but</FONT>
<BR><FONT SIZE=3D2>&gt; remember -- with SIP, the SIGNALING path is not =
necessarily thesame as the</FONT>
<BR><FONT SIZE=3D2>&gt; MEDIA path. And the timers apply to the =
SIGNALING path.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Many of the architectures I'm seeing have three =
thousand kilometers, ten</FONT>
<BR><FONT SIZE=3D2>&gt; routers, and six proxies between two SIP =
endpoints.&nbsp; Assuming 6ms/1000km,</FONT>
<BR><FONT SIZE=3D2>&gt; 10ms/router, and 50ms/proxy, that works out to =
418ms each way, or a total of</FONT>
<BR><FONT SIZE=3D2>&gt; 836ms round trip. With default settings, the =
originating UA is going to</FONT>
<BR><FONT SIZE=3D2>&gt; resend its INVITE after only 500ms unless =
response is received. Everybody</FONT>
<BR><FONT SIZE=3D2>&gt; wants to use stateless proxies for performance =
reaons. So, nearly every</FONT>
<BR><FONT SIZE=3D2>&gt; INVITE gets sent twice. This can be severely =
detrimental to the function of</FONT>
<BR><FONT SIZE=3D2>&gt; a proxy that is operating at near peak capacity =
-- in fact, it basically</FONT>
<BR><FONT SIZE=3D2>&gt; cuts the peak capacity of a proxy in half =
whenever proxy chains are</FONT>
<BR><FONT SIZE=3D2>&gt; configured in such a way that T1 is regularly =
exceeded.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; There are a couple of alternatives that come to =
mind:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1) Deploy faster proxies.</FONT>
<BR><FONT SIZE=3D2>&gt; 2) Deploy 100-generating proxies at all levels =
to prevent timer expiration</FONT>
<BR><FONT SIZE=3D2>&gt; due to downstream latency.</FONT>
<BR><FONT SIZE=3D2>&gt; 3) Change the default timers.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thoughts?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; Dean Willis</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; SIP mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; SIP@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/sip" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></F=
ONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>SIP mailing list</FONT>
<BR><FONT SIZE=3D2>SIP@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/sip" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></F=
ONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C075CE.BE893630--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 16:57:08 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05923
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 16:57:08 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9852244344; Wed,  3 Jan 2001 15:57:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id 78ADA44336
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 15:56:53 -0500 (EST)
Received: from cowboys (IDENT:root@localhost [127.0.0.1])
	by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id EAA20033;
	Thu, 4 Jan 2001 04:02:28 -0600
Message-ID: <00d101c075cf$9f238880$ea036e3f@dynamicsoft.com>
From: "Dean Willis" <dean.willis@softarmor.com>
To: "Itamar Gilad" <ItamarG@tlv.radvision.com>,
        "'SIP List'" <sip@lists.bell-labs.com>
References: <E09383987EE5D3119F2E0008C7097728014D74A0@nt-mail.tlv.radvision.com>
Subject: Re: [SIP] open issues BOF - question
MIME-Version: 1.0
Content-Type: text/plain;
	charset="WINDOWS-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 15:53:33 -0600
Content-Transfer-Encoding: 7bit


The notes as posted are all that anybody has sent me. If there are unclear
points (which there appear to be) perhaps the parties involved could comment
further on the issue? I'll be happy to amend the notes as part of the
minutes process.

--
Dean

----- Original Message -----
From: "Itamar Gilad" <ItamarG@tlv.radvision.com>
To: "'SIP List'" <sip@lists.bell-labs.com>
Sent: Wednesday, January 03, 2001 9:05 AM
Subject: [SIP] open issues BOF - question


> Dean, others,
>
> Thanks for publishing the meeting minutes of the Open Issues BOF held in
> San-Diego
>
(http://www.softarmor.com/sipwg/meets/ietf49/minutes/openissues-demirtjis.ht
> m).
> Q: Is this the final thing?  It's sort of written in short-hand and I'm
not
> quite sure I understand what was actually decided in regard to early
media.
>
> Thanks,
>
> Itamar Gilad
> RADVision 24 Raul Wallenberg St.
> itamarg@tlv.radvision.com Building D
> tel: +972 3 7659938 Tel-Aviv 69719
> fax: +972 3 6442903 Israel
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 17:21:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06448
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 17:21:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 47C1344337; Wed,  3 Jan 2001 16:22:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from selene.cps.intel.com (selene.cps.intel.com [192.198.165.10])
	by lists.bell-labs.com (Postfix) with ESMTP id A5F1944336
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 16:21:43 -0500 (EST)
Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204])
	by selene.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id OAA00174
	for <sip@lists.bell-labs.com>; Wed, 3 Jan 2001 14:21:32 -0800 (PST)
Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 03 Jan 2001 22:21:32 0000 (GMT)
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <Z6APGPZQ>; Wed, 3 Jan 2001 14:21:31 -0800
Message-ID: <4148FEAAD879D311AC5700A0C969E8902D490B@orsmsx35.jf.intel.com>
From: "Gross, Gerhard" <gerhard.gross@intel.com>
To: sip@lists.bell-labs.com
Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 14:21:22 -0800



> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Wednesday, January 03, 2001 1:04 PM
> To: Gross, Gerhard
> Cc: sip@lists.bell-labs.com
> Subject: Re: [aboba@internaut.com: Re: [SIP] 
> draft-calhoun-sip-aaa-req]
> 
> 
> "Gross, Gerhard" wrote:
> > 
> > >Instead of re-casting the SIP request into another format and
> > >translating status codes between protocols, why not just 
> proxy the SIP
> > >request to whatever database/server decides whether the person has
> > >subscribed to this service?
> > 
> > One reason is for simplicity and to potentially
> > increase processing speed. This is done by taking
> > advantage of the SIP parser already built into
> > the SIP proxy. If the whole SIP message were
> > just forwarded as is to the PDP (policy decision
> > point), the PDP would need some sort of SIP
> > parser (thus adding complexity/redundancy to
> > the chain).
> 
> "Henning, Schulzrinne" wrote:
> This assumes that SIP parsing is a major delay or processing expense.
> Experience seems to indicate that it is not, compared to the typical
> database lookups, crypto and other operations that need to take place.

Understood. A different reason to re-format the SIP
message at the SIP proxy before sending it off to
a AAA/policy server is because different SIP methods
may need to be forwarded, in addition to an INVITE.
Examples are 2xx responses and ACK during call
setup and REGISTER otherwise. 2xx and ACK messages
may contain session information (due to negotiation)
that is relevant to local policy decision making.

In the re-format case, the information is packaged
in the same structure in all cases and sent to the
PDP. Simple for the PDP to parse the same structure
each time. If the raw SIP message were forwarded the
PDP would need code to parse each message (which
may be a negligible time delay but adds complexity
to the PDP).

In the end, it doesn't really matter to me whether
we re-format the SIP messages or just forward them.
Just looking to consider all angles before a choice
is made :>)

> 
> > 
> > On the other hand, while the SIP proxy parses the
> > SIP message, it may extract certain information
> > from it and put it in a simpler and smaller structure
> > to be passed on to the PDP (AAA/policy server). Such
> > a structure/protocol has been defined in
> > http://search.ietf.org/internet-drafts/draft-gross-cops-sip-00.txt.
> > 
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 17:26:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06576
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 17:26:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5E1D444373; Wed,  3 Jan 2001 16:27:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 3A70244337
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 16:26:26 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA02065;
	Wed, 3 Jan 2001 17:26:12 -0500 (EST)
Message-ID: <3A53A705.9919919E@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Gross, Gerhard" <gerhard.gross@intel.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
References: <4148FEAAD879D311AC5700A0C969E8902D490B@orsmsx35.jf.intel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 03 Jan 2001 17:26:13 -0500
Content-Transfer-Encoding: 7bit

"Gross, Gerhard" wrote:
> 
> > -----Original Message-----
> > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Wednesday, January 03, 2001 1:04 PM
> > To: Gross, Gerhard
> > Cc: sip@lists.bell-labs.com
> > Subject: Re: [aboba@internaut.com: Re: [SIP]
> > draft-calhoun-sip-aaa-req]
> >
> >
> > "Gross, Gerhard" wrote:
> > >
> > > >Instead of re-casting the SIP request into another format and
> > > >translating status codes between protocols, why not just
> > proxy the SIP
> > > >request to whatever database/server decides whether the person has
> > > >subscribed to this service?
> > >
> > > One reason is for simplicity and to potentially
> > > increase processing speed. This is done by taking
> > > advantage of the SIP parser already built into
> > > the SIP proxy. If the whole SIP message were
> > > just forwarded as is to the PDP (policy decision
> > > point), the PDP would need some sort of SIP
> > > parser (thus adding complexity/redundancy to
> > > the chain).
> >
> > "Henning, Schulzrinne" wrote:
> > This assumes that SIP parsing is a major delay or processing expense.
> > Experience seems to indicate that it is not, compared to the typical
> > database lookups, crypto and other operations that need to take place.
> 
> Understood. A different reason to re-format the SIP
> message at the SIP proxy before sending it off to
> a AAA/policy server is because different SIP methods
> may need to be forwarded, in addition to an INVITE.
> Examples are 2xx responses and ACK during call
> setup and REGISTER otherwise. 2xx and ACK messages
> may contain session information (due to negotiation)
> that is relevant to local policy decision making.
> 

Obviously, 200s (and any other response) will traverse the same proxy
chain that the requests were sent through. The parsing difference 
between requests and responses is roughly ten lines of code, if that.
(With use of scanf, it's probably one line...)


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 18:40:10 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09762
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 18:40:09 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A791D44337; Wed,  3 Jan 2001 17:39:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id A538244336
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 17:38:27 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA23405;
	Wed, 3 Jan 2001 18:40:54 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBPFB>; Wed, 3 Jan 2001 18:35:21 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAF94@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Brian Stucker'" <bstucker@nortelnetworks.com>,
        Sean Olson <sean.olson@ericsson.com>,
        Dean Willis <dean.willis@softarmor.com>
Cc: "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
Subject: RE: [SIP] Discussion of Default Timers
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 18:35:20 -0500



  
-----Original Message-----
>From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
>Sent: Wednesday, January 03, 2001 4:47 PM
>To: Sean Olson; Dean Willis
>Cc: IETF SIP (E-mail)
>Subject: RE: [SIP] Discussion of Default Timers
>
>
>Ah... Should have read further back into the thread than I did. 
>If I read 2543 correctly, it already allows for timers on the clients to be
autonomously 
>extended (but not shortened) by the client without any server interaction.

Correct. This is the purpose of the Timestamp header. The client places it
in a request, and its mirrored in the response. The client can use the
measured RTT to adjust its timer. The information can be cached or
remeasured as needed. This solves the problem that has been discussed in
this thread.

>I guess I would recommend that we consider adding the following (along the
lines of the 
>retry-after header): 

There is no need for this header, as far as I can tell. I don't see why the
server would tell the client what to do here.

What is needed is a way for the server to measure the RTT to the client and
back; thats possible by allowing the Timestamp header to be placed in the
final response, and then have it reflected back in the ACK. This is not in
rfc2543. It can be added to bis if people feel strongly about it. 

Henning wrote:
> 4) Use fewer proxies. I have a hard time seeing why you 
> really need more
> than two (outbound and inbound) proxy in most cases. This 
> should be true
> for email as well (there are two hops to the list and two 
> from the list
> to me), although there seem to be companies where email hops along
> internally for various Notes/Exchange/IBM Profs translators and who
> knows what else.

I think you will see much more than two. In large, deployed networks,
hierarchy is introduced in order to provide manageability and better scale.
Many of the providers I have spoken to are deploying several layers of
proxies in order to build out their networks. Furthermore, SIP calls may
traverse proxies that provide specific services, increasing the count. A
good way to get a feel for the likely count is to count how many message
transfer agents an email passes through; these are akin to proxies in their
role as routing devices. You will probably see that it is many.

Jon Peterson wrote:
Stateless 
> proxies used
> for load sharing or fault tolerance, however, will go away, I 
> think; they'll
> be replaced by hardware load-balancers, or what have you, 
> that will provide
> scale and availability at near-router costs in latency. So, I 
> suppose from
> my perspective it is realistic to adopt the 'deploy fewer proxies'
> philosophy in the long term.

I think that depends on how you want to do the balancing. A proxy is
different than a hardware load balancer in that it can perform smarter
SIP-layer-aware processing. For example, a good stateless SIP proxy might
divide up phone calls and route them amongst gateways based on phone
prefixes. In some sense, this is load balancing, and in others, its not.
Hardware load balancers are useful for creating a large "virtual" proxy that
appears to the SIP network like a single proxy, although its constructed
with many actual proxies, each hiding behind a load balancer. This is
because hardware balancers are only good at distributing load across
homogenous devices. When the devices you want to load balance across are not
homogeneous, and the routing decision becomes application specific, you want
a proxy, not a hardware load balancer.

-Jonathan R.




---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 18:56:05 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09958
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 18:56:05 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 87AB144344; Wed,  3 Jan 2001 17:56:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by lists.bell-labs.com (Postfix) with ESMTP id 15C1D44337
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 17:55:04 -0500 (EST)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch1.nortel.com; Wed, 3 Jan 2001 17:51:54 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <Z8FFQXRX>; Wed, 3 Jan 2001 17:51:47 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43AA5F61@crchy271.us.nortel.com>
From: "Brian Stucker" <bstucker@nortelnetworks.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Sean Olson <sean.olson@ericsson.com>,
        Dean Willis <dean.willis@softarmor.com>
Cc: "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
Subject: RE: [SIP] Discussion of Default Timers
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C075E0.227FF870"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 17:51:47 -0600

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_01C075E0.227FF870
Content-Type: text/plain;
	charset="iso-8859-1"

I can think of a reason you might not get the information you need with a
timestamp header. What if the proxy suspects (by some algorithm, possibly
averaged timestamps) that a particular route or set of routes is going to
exceed the default timers that the client may be using? It would be nice to
tell the client as fast as possible (ie. on a provisional response) that
outbound legs beyond the proxy are likely to take awhile to process a
request.

Take the example a UA sitting on a LAN sends an INVITE to his local proxy,
and the proxy forwards that INVITE to another proxy that serves a wireless
network which sends it off to the wireless UA.

The timestamp (if I understand how you're using it correctly) would either
report one of two conditions:

1. The timestamp would bounce back in the 1xx response to the LAN UA and
show a short time interval (say 20ms) round-trip, which wouldn't correctly
characterize the actual time it's going to take for the entire signalling
path to complete.

2. The timestamp would bounce back from the wireless UA, possibly AFTER the
timers had expired on the LAN UA.

It would be useful if instead, the wireless network proxy could tell the LAN
proxy, "Hey, I'm slow, here's some reasonable timers to use for this call"
which the LAN proxy could then send back to the LAN UA to adjust their
settings.

-or-

If the LAN proxy through some method of discovery (datafill, network
analysis, etc.) had enough reason to believe that the call would take awhile
(i.e. routing to a .ch domain from a .uk domain; or any requests that are
routing to a known wireless data network) tell the UA immediately in the
provisional 1xx response.

According to the copy of RFC-2543bis02 that I'm looking at, the timestamp
will only take care of the first leg, and only by letting the client time
the request (which he could do without the header anyhow). It doesn't appear
to me that it helps with downstream adjustments. Maybe I'm reading it wrong.

I could see where it would be pretty useful to let proxies signal the
current network condition outside of the local network to the client.

Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Wednesday, January 03, 2001 5:35 PM
To: Stucker, Brian [RICH2:WI41:EXCH]; Sean Olson; Dean Willis
Cc: IETF SIP (E-mail)
Subject: RE: [SIP] Discussion of Default Timers




  
-----Original Message-----
>From: Brian Stucker [mailto:bstucker@nortelnetworks.com]
>Sent: Wednesday, January 03, 2001 4:47 PM
>To: Sean Olson; Dean Willis
>Cc: IETF SIP (E-mail)
>Subject: RE: [SIP] Discussion of Default Timers
>
>
>Ah... Should have read further back into the thread than I did. 
>If I read 2543 correctly, it already allows for timers on the clients to be
autonomously 
>extended (but not shortened) by the client without any server interaction.

Correct. This is the purpose of the Timestamp header. The client places it
in a request, and its mirrored in the response. The client can use the
measured RTT to adjust its timer. The information can be cached or
remeasured as needed. This solves the problem that has been discussed in
this thread.

>I guess I would recommend that we consider adding the following (along the
lines of the 
>retry-after header): 

There is no need for this header, as far as I can tell. I don't see why the
server would tell the client what to do here.

What is needed is a way for the server to measure the RTT to the client and
back; thats possible by allowing the Timestamp header to be placed in the
final response, and then have it reflected back in the ACK. This is not in
rfc2543. It can be added to bis if people feel strongly about it. 

Henning wrote:
> 4) Use fewer proxies. I have a hard time seeing why you 
> really need more
> than two (outbound and inbound) proxy in most cases. This 
> should be true
> for email as well (there are two hops to the list and two 
> from the list
> to me), although there seem to be companies where email hops along
> internally for various Notes/Exchange/IBM Profs translators and who
> knows what else.

I think you will see much more than two. In large, deployed networks,
hierarchy is introduced in order to provide manageability and better scale.
Many of the providers I have spoken to are deploying several layers of
proxies in order to build out their networks. Furthermore, SIP calls may
traverse proxies that provide specific services, increasing the count. A
good way to get a feel for the likely count is to count how many message
transfer agents an email passes through; these are akin to proxies in their
role as routing devices. You will probably see that it is many.

Jon Peterson wrote:
Stateless 
> proxies used
> for load sharing or fault tolerance, however, will go away, I 
> think; they'll
> be replaced by hardware load-balancers, or what have you, 
> that will provide
> scale and availability at near-router costs in latency. So, I 
> suppose from
> my perspective it is realistic to adopt the 'deploy fewer proxies'
> philosophy in the long term.

I think that depends on how you want to do the balancing. A proxy is
different than a hardware load balancer in that it can perform smarter
SIP-layer-aware processing. For example, a good stateless SIP proxy might
divide up phone calls and route them amongst gateways based on phone
prefixes. In some sense, this is load balancing, and in others, its not.
Hardware load balancers are useful for creating a large "virtual" proxy that
appears to the SIP network like a single proxy, although its constructed
with many actual proxies, each hiding behind a load balancer. This is
because hardware balancers are only good at distributing load across
homogenous devices. When the devices you want to load balance across are not
homogeneous, and the routing decision becomes application specific, you want
a proxy, not a hardware load balancer.

-Jonathan R.




---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

------_=_NextPart_001_01C075E0.227FF870
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [SIP] Discussion of Default Timers</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I can think of a reason you might not get the =
information you need with a timestamp header. What if the proxy =
suspects (by some algorithm, possibly averaged timestamps) that a =
particular route or set of routes is going to exceed the default timers =
that the client may be using? It would be nice to tell the client as =
fast as possible (ie. on a provisional response) that outbound legs =
beyond the proxy are likely to take awhile to process a =
request.</FONT></P>

<P><FONT SIZE=3D2>Take the example a UA sitting on a LAN sends an =
INVITE to his local proxy, and the proxy forwards that INVITE to =
another proxy that serves a wireless network which sends it off to the =
wireless UA.</FONT></P>

<P><FONT SIZE=3D2>The timestamp (if I understand how you're using it =
correctly) would either report one of two conditions:</FONT>
</P>

<P><FONT SIZE=3D2>1. The timestamp would bounce back in the 1xx =
response to the LAN UA and show a short time interval (say 20ms) =
round-trip, which wouldn't correctly characterize the actual time it's =
going to take for the entire signalling path to complete.</FONT></P>

<P><FONT SIZE=3D2>2. The timestamp would bounce back from the wireless =
UA, possibly AFTER the timers had expired on the LAN UA.</FONT>
</P>

<P><FONT SIZE=3D2>It would be useful if instead, the wireless network =
proxy could tell the LAN proxy, &quot;Hey, I'm slow, here's some =
reasonable timers to use for this call&quot; which the LAN proxy could =
then send back to the LAN UA to adjust their settings.</FONT></P>

<P><FONT SIZE=3D2>-or-</FONT>
</P>

<P><FONT SIZE=3D2>If the LAN proxy through some method of discovery =
(datafill, network analysis, etc.) had enough reason to believe that =
the call would take awhile (i.e. routing to a .ch domain from a .uk =
domain; or any requests that are routing to a known wireless data =
network) tell the UA immediately in the provisional 1xx =
response.</FONT></P>

<P><FONT SIZE=3D2>According to the copy of RFC-2543bis02 that I'm =
looking at, the timestamp will only take care of the first leg, and =
only by letting the client time the request (which he could do without =
the header anyhow). It doesn't appear to me that it helps with =
downstream adjustments. Maybe I'm reading it wrong.</FONT></P>

<P><FONT SIZE=3D2>I could see where it would be pretty useful to let =
proxies signal the current network condition outside of the local =
network to the client.</FONT></P>

<P><FONT SIZE=3D2>Brian</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Jonathan Rosenberg [<A =
HREF=3D"mailto:jdrosen@dynamicsoft.com">mailto:jdrosen@dynamicsoft.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, January 03, 2001 5:35 PM</FONT>
<BR><FONT SIZE=3D2>To: Stucker, Brian [RICH2:WI41:EXCH]; Sean Olson; =
Dean Willis</FONT>
<BR><FONT SIZE=3D2>Cc: IETF SIP (E-mail)</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [SIP] Discussion of Default =
Timers</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;From: Brian Stucker [<A =
HREF=3D"mailto:bstucker@nortelnetworks.com">mailto:bstucker@nortelnetwor=
ks.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt;Sent: Wednesday, January 03, 2001 4:47 PM</FONT>
<BR><FONT SIZE=3D2>&gt;To: Sean Olson; Dean Willis</FONT>
<BR><FONT SIZE=3D2>&gt;Cc: IETF SIP (E-mail)</FONT>
<BR><FONT SIZE=3D2>&gt;Subject: RE: [SIP] Discussion of Default =
Timers</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Ah... Should have read further back into the =
thread than I did. </FONT>
<BR><FONT SIZE=3D2>&gt;If I read 2543 correctly, it already allows for =
timers on the clients to be</FONT>
<BR><FONT SIZE=3D2>autonomously </FONT>
<BR><FONT SIZE=3D2>&gt;extended (but not shortened) by the client =
without any server interaction.</FONT>
</P>

<P><FONT SIZE=3D2>Correct. This is the purpose of the Timestamp header. =
The client places it</FONT>
<BR><FONT SIZE=3D2>in a request, and its mirrored in the response. The =
client can use the</FONT>
<BR><FONT SIZE=3D2>measured RTT to adjust its timer. The information =
can be cached or</FONT>
<BR><FONT SIZE=3D2>remeasured as needed. This solves the problem that =
has been discussed in</FONT>
<BR><FONT SIZE=3D2>this thread.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;I guess I would recommend that we consider adding =
the following (along the</FONT>
<BR><FONT SIZE=3D2>lines of the </FONT>
<BR><FONT SIZE=3D2>&gt;retry-after header): </FONT>
</P>

<P><FONT SIZE=3D2>There is no need for this header, as far as I can =
tell. I don't see why the</FONT>
<BR><FONT SIZE=3D2>server would tell the client what to do here.</FONT>
</P>

<P><FONT SIZE=3D2>What is needed is a way for the server to measure the =
RTT to the client and</FONT>
<BR><FONT SIZE=3D2>back; thats possible by allowing the Timestamp =
header to be placed in the</FONT>
<BR><FONT SIZE=3D2>final response, and then have it reflected back in =
the ACK. This is not in</FONT>
<BR><FONT SIZE=3D2>rfc2543. It can be added to bis if people feel =
strongly about it. </FONT>
</P>

<P><FONT SIZE=3D2>Henning wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; 4) Use fewer proxies. I have a hard time seeing =
why you </FONT>
<BR><FONT SIZE=3D2>&gt; really need more</FONT>
<BR><FONT SIZE=3D2>&gt; than two (outbound and inbound) proxy in most =
cases. This </FONT>
<BR><FONT SIZE=3D2>&gt; should be true</FONT>
<BR><FONT SIZE=3D2>&gt; for email as well (there are two hops to the =
list and two </FONT>
<BR><FONT SIZE=3D2>&gt; from the list</FONT>
<BR><FONT SIZE=3D2>&gt; to me), although there seem to be companies =
where email hops along</FONT>
<BR><FONT SIZE=3D2>&gt; internally for various Notes/Exchange/IBM Profs =
translators and who</FONT>
<BR><FONT SIZE=3D2>&gt; knows what else.</FONT>
</P>

<P><FONT SIZE=3D2>I think you will see much more than two. In large, =
deployed networks,</FONT>
<BR><FONT SIZE=3D2>hierarchy is introduced in order to provide =
manageability and better scale.</FONT>
<BR><FONT SIZE=3D2>Many of the providers I have spoken to are deploying =
several layers of</FONT>
<BR><FONT SIZE=3D2>proxies in order to build out their networks. =
Furthermore, SIP calls may</FONT>
<BR><FONT SIZE=3D2>traverse proxies that provide specific services, =
increasing the count. A</FONT>
<BR><FONT SIZE=3D2>good way to get a feel for the likely count is to =
count how many message</FONT>
<BR><FONT SIZE=3D2>transfer agents an email passes through; these are =
akin to proxies in their</FONT>
<BR><FONT SIZE=3D2>role as routing devices. You will probably see that =
it is many.</FONT>
</P>

<P><FONT SIZE=3D2>Jon Peterson wrote:</FONT>
<BR><FONT SIZE=3D2>Stateless </FONT>
<BR><FONT SIZE=3D2>&gt; proxies used</FONT>
<BR><FONT SIZE=3D2>&gt; for load sharing or fault tolerance, however, =
will go away, I </FONT>
<BR><FONT SIZE=3D2>&gt; think; they'll</FONT>
<BR><FONT SIZE=3D2>&gt; be replaced by hardware load-balancers, or what =
have you, </FONT>
<BR><FONT SIZE=3D2>&gt; that will provide</FONT>
<BR><FONT SIZE=3D2>&gt; scale and availability at near-router costs in =
latency. So, I </FONT>
<BR><FONT SIZE=3D2>&gt; suppose from</FONT>
<BR><FONT SIZE=3D2>&gt; my perspective it is realistic to adopt the =
'deploy fewer proxies'</FONT>
<BR><FONT SIZE=3D2>&gt; philosophy in the long term.</FONT>
</P>

<P><FONT SIZE=3D2>I think that depends on how you want to do the =
balancing. A proxy is</FONT>
<BR><FONT SIZE=3D2>different than a hardware load balancer in that it =
can perform smarter</FONT>
<BR><FONT SIZE=3D2>SIP-layer-aware processing. For example, a good =
stateless SIP proxy might</FONT>
<BR><FONT SIZE=3D2>divide up phone calls and route them amongst =
gateways based on phone</FONT>
<BR><FONT SIZE=3D2>prefixes. In some sense, this is load balancing, and =
in others, its not.</FONT>
<BR><FONT SIZE=3D2>Hardware load balancers are useful for creating a =
large &quot;virtual&quot; proxy that</FONT>
<BR><FONT SIZE=3D2>appears to the SIP network like a single proxy, =
although its constructed</FONT>
<BR><FONT SIZE=3D2>with many actual proxies, each hiding behind a load =
balancer. This is</FONT>
<BR><FONT SIZE=3D2>because hardware balancers are only good at =
distributing load across</FONT>
<BR><FONT SIZE=3D2>homogenous devices. When the devices you want to =
load balance across are not</FONT>
<BR><FONT SIZE=3D2>homogeneous, and the routing decision becomes =
application specific, you want</FONT>
<BR><FONT SIZE=3D2>a proxy, not a hardware load balancer.</FONT>
</P>

<P><FONT SIZE=3D2>-Jonathan R.</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>---</FONT>
<BR><FONT SIZE=3D2>Jonathan D. =
Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
72 Eagle Rock Ave.</FONT>
<BR><FONT SIZE=3D2>Chief =
Scientist&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; First Floor</FONT>
<BR><FONT =
SIZE=3D2>dynamicsoft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
East Hanover, NJ 07936</FONT>
<BR><FONT =
SIZE=3D2>jdrosen@dynamicsoft.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; FAX:&nbsp;&nbsp; (973) 952-5050</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.cs.columbia.edu/~jdrosen" =
TARGET=3D"_blank">http://www.cs.columbia.edu/~jdrosen</A>&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PHONE: (973) 952-5000</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.dynamicsoft.com" =
TARGET=3D"_blank">http://www.dynamicsoft.com</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C075E0.227FF870--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan  3 20:21:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11377
	for <sip-archive@odin.ietf.org>; Wed, 3 Jan 2001 20:21:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0B4DB44337; Wed,  3 Jan 2001 19:22:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4])
	by lists.bell-labs.com (Postfix) with SMTP id 84F5744336
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 19:21:17 -0500 (EST)
Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP (
 Tumbleweed MMS SMTP Relay (MMS v4.7)); Wed, 03 Jan 2001 17:20:39 -0800
X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900
Received: by mailserver.sylantro.com with Internet Mail Service (
 5.5.2653.19) id <CH6K9Z67>; Wed, 3 Jan 2001 17:20:39 -0800
Message-ID: <79FEAA5FABA7D411BF580001023D1BBD1A3DD1@mailserver.sylantro.com>
From: "Sharath Rajasekar" <Sharath.Rajasekar@sylantro.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 164D106D14481-01-01
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Subject: [SIP] ACK Processing in stateless proxies
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 3 Jan 2001 17:20:39 -0800
Content-Transfer-Encoding: 7bit


We consider a case of two UAs, A and B, along with two 
proxies P1 and P2. Both proxies are "stateless" and record
route. 

--1)
	A       P1       P2       B
      |        |        |        |        
      |--INV-->|--INV-->|--INV-->|
      |        |        |        |
      |<-100---|<-100---|<-100---|
      |        |        |        |
      |        |        |<-404---|
      |        |        |--ACK-->|
      |        |        |        |
	|	   |<-404---|        |
      |        |--ACK-->|        |
      |        |        |        |
      |<-404---|        |        |
	|--ACK-->|        |        |
      |        |        |        |


Would the two stateless proxies P1 and P2 propagate
ACKs as shown above or would they do so as shown below ?

--2)
	A       P1       P2       B
      |        |        |        |        
      |--INV-->|--INV-->|--INV-->|
      |        |        |        |
      |<-100---|<-100---|<-100---|
      |        |        |        |
      |<-404---|<-404---|<-404---|
      |        |        |        |
      |--ACK-->|--ACK-->|--ACK-->|
      |        |        |        |

(A)
The bis draft in section 12.3 Proxy Server mentions 
that "A stateless proxy forwards every request it receives 
downstream, and every response it receives upstream". Note 
there is no MUST, SHOULD or MAY.

(B)
"Stateful" proxies as the draft implies on the other hand
would have to process any response with status code < 300 
and status code equal to 401 or 484 as 2) [end-to-end] and 
the remaining responses as 1) [hop-by-hop].

How SHOULD, MUST or MAY "stateless" proxies process ACKs ?

Thanks
Sharath




_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 00:19:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16232
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 00:19:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8D1FC44337; Wed,  3 Jan 2001 23:20:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from hindon.hss.co.in (unknown [202.54.26.202])
	by lists.bell-labs.com (Postfix) with ESMTP id 865A544336
	for <sip@lists.bell-labs.com>; Wed,  3 Jan 2001 23:19:50 -0500 (EST)
Received: from hsssun01.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f045KxT27821
	for <sip@lists.bell-labs.com>; Thu, 4 Jan 2001 10:51:00 +0530 (IST)
Received: from sampark.hss.hns.com (sampark [139.85.229.22])
	by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id f045SlY19776
	for <sip@lists.bell-labs.com>; Thu, 4 Jan 2001 10:58:52 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 652569CA.001D6E48 ; Thu, 4 Jan 2001 10:51:27 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: sip@lists.bell-labs.com
Message-ID: <652569CA.001D6C72.00@sampark.hss.hns.com>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] Clarification of para in 100-rel-02.txt
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 10:51:22 +0530



Hi,
please refer to sec 5.2 of the rel-02 draft (june 30, 2000)

"Note that the UAS MAY send a final response to the initial request
before having received PRACKs for all outstanding reliable
provisional responses. However, it MUST be prepared to process PRACK
requests for those outstanding responses. A UAS MUST NOT send
reliable provisional responses after sending a final response to a
request."

The clarificartion is wrt to the last line. Does it mean that the

1)  UAS MUST not send any new rel prov. responses after sending the final
response
or
does it mean that
2)  the UAS must stop retransmission of its old non PRACKed rel prov.
responses + 1)


I feel its the former - I may have sent some early media information in my
1xx response which
I want to make sure he has got. The reason I sent 200 OK quickly is for
faster call processing, but I
still want to know if he got my earlier 1xx. So retransmissions of old 1xx
should not stop even if I sent
a final response.

Is this correct ?
Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems




_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 01:35:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20117
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 01:35:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3009244337; Thu,  4 Jan 2001 00:36:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id D850E44336
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 00:35:55 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA24984;
	Thu, 4 Jan 2001 01:37:12 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBPRQ>; Thu, 4 Jan 2001 01:31:39 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAF9D@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        Brian Stucker <bstucker@nortelnetworks.com>
Cc: Ashhar Farhan <afarhan@rediffmail.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] a tiny binary sip proxy protocol
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 01:31:39 -0500

And more importantly, this is nothing more than yet another signaling
protocol for VoIP. If you wish to propose a new working group in IETF to
standardize such a thing, you are welcome to try. However, it is not SIP and
discussion of this new protocol does not belong on this list.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Wednesday, January 03, 2001 4:07 PM
> To: Brian Stucker
> Cc: Ashhar Farhan; sip@lists.bell-labs.com
> Subject: Re: [SIP] a tiny binary sip proxy protocol
> 
> 
> Thanks for solving a non-problem (parsing expense). Can we move on to
> other, more pressing concerns?
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 01:38:32 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20388
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 01:38:31 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7184E4434C; Thu,  4 Jan 2001 00:37:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 4B6D544349
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 00:36:47 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA25007;
	Thu, 4 Jan 2001 01:39:20 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBPRW>; Thu, 4 Jan 2001 01:33:46 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAF9E@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'archow@hss.hns.com'" <archow@hss.hns.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Clarification of para in 100-rel-02.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 01:33:46 -0500



 

> -----Original Message-----
> From: archow@hss.hns.com [mailto:archow@hss.hns.com]
> Sent: Thursday, January 04, 2001 12:21 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Clarification of para in 100-rel-02.txt
> 
> 
> 
> 
> Hi,
> please refer to sec 5.2 of the rel-02 draft (june 30, 2000)
> 
> "Note that the UAS MAY send a final response to the initial request
> before having received PRACKs for all outstanding reliable
> provisional responses. However, it MUST be prepared to process PRACK
> requests for those outstanding responses. A UAS MUST NOT send
> reliable provisional responses after sending a final response to a
> request."
> 
> The clarificartion is wrt to the last line. Does it mean that the
> 
> 1)  UAS MUST not send any new rel prov. responses after 
> sending the final
> response
> or
> does it mean that
> 2)  the UAS must stop retransmission of its old non PRACKed rel prov.
> responses + 1)
> 
> 
> I feel its the former - I may have sent some early media 
> information in my
> 1xx response which
> I want to make sure he has got. 


Correct. It is new provisional responses you are not supposed to send.
Existing ones in flight should complete normally. I'll clarify that.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 01:44:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21183
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 01:44:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6A59244360; Thu,  4 Jan 2001 00:45:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 1CC584434C
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 00:44:39 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA25039;
	Thu, 4 Jan 2001 01:47:11 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBPR9>; Thu, 4 Jan 2001 01:41:37 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAF9F@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Sharath Rajasekar'" <Sharath.Rajasekar@sylantro.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] RE: ACK Processing in stateless proxies
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 01:41:36 -0500



 

> -----Original Message-----
> From: Sharath Rajasekar [mailto:Sharath.Rajasekar@sylantro.com]
> Sent: Wednesday, January 03, 2001 8:21 PM
> To: Jonathan Rosenberg
> Cc: IETF SIP (E-mail)
> Subject: ACK Processing in stateless proxies
> 
> 
> 
> We consider a case of two UAs, A and B, along with two 
> proxies P1 and P2. Both proxies are "stateless" and record
> route. 
> 
> --1)
> 	A       P1       P2       B
>       |        |        |        |        
>       |--INV-->|--INV-->|--INV-->|
>       |        |        |        |
>       |<-100---|<-100---|<-100---|
>       |        |        |        |
>       |        |        |<-404---|
>       |        |        |--ACK-->|
>       |        |        |        |
> 	|	   |<-404---|        |
>       |        |--ACK-->|        |
>       |        |        |        |
>       |<-404---|        |        |
> 	|--ACK-->|        |        |
>       |        |        |        |
> 
> 

This flow is not correct. The stateless proxies would not generate an ACK.
THey would forward the response upstream.


> Would the two stateless proxies P1 and P2 propagate
> ACKs as shown above or would they do so as shown below ?
> 
> --2)
> 	A       P1       P2       B
>       |        |        |        |        
>       |--INV-->|--INV-->|--INV-->|
>       |        |        |        |
>       |<-100---|<-100---|<-100---|
>       |        |        |        |
>       |<-404---|<-404---|<-404---|
>       |        |        |        |
>       |--ACK-->|--ACK-->|--ACK-->|
>       |        |        |        |

This second flow is correct.

> 
> (A)
> The bis draft in section 12.3 Proxy Server mentions 
> that "A stateless proxy forwards every request it receives 
> downstream, and every response it receives upstream". Note 
> there is no MUST, SHOULD or MAY.

Statements of that type are MUST. This is something we are aiming to be more
explicit about in the upcoming bis drafts.

> 
> (B)
> "Stateful" proxies as the draft implies on the other hand
> would have to process any response with status code < 300 
> and status code equal to 401 or 484 as 2) [end-to-end] and 
> the remaining responses as 1) [hop-by-hop].

No. A stateful proxy would "process" any final response except a 200 class
response. This means it will generate an ACK for anything but a 200 class
response. 

> 
> How SHOULD, MUST or MAY "stateless" proxies process ACKs ?

If your proxy is processing an ACK, its not stateless by definition.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 01:51:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22077
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 01:51:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3F33644373; Thu,  4 Jan 2001 00:52:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 608B144372
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 00:51:04 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA25080;
	Thu, 4 Jan 2001 01:53:36 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBPS2>; Thu, 4 Jan 2001 01:48:02 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAFA0@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'David Israel'" <david@ipunity.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Setting Via field in Responses
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 01:48:01 -0500



 

> -----Original Message-----
> From: David Israel [mailto:david@ipunity.com]
> Sent: Wednesday, January 03, 2001 1:40 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Setting Via field in Responses
> 
> 
> 
> The spec says that the Via field in a Response is to be set 
> to the client or
> proxy processing the message. 

No, the Via field in the response is copied from the via field in the
request:

>6.47.4 User Agent and Redirect Servers
>A UAS or redirect server copies the Via header fields into the response,
without changing 
>their order, and
>uses the top (first) Via element as the destination, as described in the
next section.



> So if you are sending the 
> response back to the
> proxy you received the request from, you would just copy over 
> the top-most
> Via field from the Request to the Response. 

No, you copy all of them.

> But what happens 
> if there is a
> Contact field in the Request,

They are mandatory in rfc2543bis now.

> and you are sending the 
> Response to the URI
> from the Contact field? 

You wouldn't do that. Section 6.47.5 is quite clear and says nothing about
Contact header for forwarding responses. The response is ALWAYS SENT TO THE
IP ADDRESS THE REQUEST CAME FROM, AT THE PORT IN THE TOPMOST VIA. That rule
is for UAs, proxies, redirect servers alike.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 01:57:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22795
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 01:57:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B7EE244372; Thu,  4 Jan 2001 00:58:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id AA6F044336
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 00:57:26 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA25096;
	Thu, 4 Jan 2001 01:59:58 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBPSM>; Thu, 4 Jan 2001 01:54:25 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAFA1@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Rami Lehtonen'" <rampe@cs.tut.fi>, sip@lists.bell-labs.com
Subject: RE: [SIP] What method should be used?
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 01:54:23 -0500



 

> -----Original Message-----
> From: Rami Lehtonen [mailto:rampe@cs.tut.fi]
> Sent: Wednesday, January 03, 2001 7:59 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] What method should be used?
> 
> 
> Hi all!
> 
> The SIP specification and the extensions defined for the SIP 
> give a lot of
> possible methods to be used for transferring parameters between two
> end-points. In our case we are interested in transferring 
> stream parameters
> to an end-point (B) that starts the session with some third 
> end-point (C),
> see the figure below:
> 
> A  --parameter transfer-->  B  <===session===>  C
> 
> So should we use the methods like INVITE or MESSAGE (or even 
> NOTIFY) to
> deliver the parameters from A to B? 

I do not know what a stream parameter is. SIP is not an RPC protocol nor a
means of generic data messaging between any two entities. If you are
interested in having some user A cause a call to be established between B
and C, you can use the REFER method:

http://search.ietf.org/internet-drafts/draft-ietf-sip-cc-transfer-02.txt

or third party call control:

http://search.ietf.org/internet-drafts/draft-rosenberg-sip-3pcc-01.txt

-Jonathan R.


---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 02:09:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29704
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 02:09:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5C51944344; Thu,  4 Jan 2001 01:10:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id B051C44337
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 01:09:59 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA25243;
	Thu, 4 Jan 2001 02:12:30 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBPTQ>; Thu, 4 Jan 2001 02:06:57 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAFA2@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'aki.niemi@nokia.com'" <aki.niemi@nokia.com>, kbinu@hss.hns.com
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Proxy Authentication sequence
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 02:06:55 -0500



 

> -----Original Message-----
> From: aki.niemi@nokia.com [mailto:aki.niemi@nokia.com]
> Sent: Tuesday, January 02, 2001 7:43 AM
> To: kbinu@hss.hns.com
> Cc: sip@lists.bell-labs.com
> Subject: RE: [SIP] Proxy Authentication sequence
> 
> 
> 
> > Hi
> >      I have a doubt regarding the authentication challenge-response
> > sequence. Consider the following call-flow:
> >      A proxy rejects an INVITE with a "407 Proxy 
> > Authentication Required"
> > response containing a challenge. The client acknowledges the 
> > response. Now
> > when the client sends an INVITE with the response to the 
> > challenge, does it
> > necessarily have to be a new call ?  The call-flows draft 
> shows a new
> > call-id being used in the next INVITE. However, is it correct 
> > if the client
> > uses an incremented CSeq number with the same call-id in 
> the new INVTE
> > containing the response to the challenge ?
> > 
> 
> Incrementing CSeq is not only correct behaviour, but also required
> behaviour. According to RFC2543, a UAC resubmitting a request with its
> credentials after a 401/407 MUST increment the CSeq. This way 
> the requests
> stay in the same call-leg, and servers can have per request 
> challenges,
> which e.g. time out after a while.
> 
> Resubmitted requests after 401/407 with a new call-id will 
> result in servers
> endlessly sending "fresh" credentials to the client.

That would only happen when you tie the value of the nonce to the Call-ID.
Probably not a good idea. Although the spec does say you have to use the
same call-id and increment the CSeq, the stateless nature of the
authentication mechanism (and the ability to cache credentials), means that
it is possible to send credentials in a brand new request. Servers should
not be rejecting these right away. Rather, nonce values should be strictly
based on time.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 02:16:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29785
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 02:16:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2C9C144344; Thu,  4 Jan 2001 01:17:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 565A444338
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 01:16:04 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA25263;
	Thu, 4 Jan 2001 02:18:35 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBPTV>; Thu, 4 Jan 2001 02:13:02 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAFA3@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Christian Huitema'" <huitema@exchange.microsoft.com>,
        Henning Schulzrinne <hgs@cs.columbia.edu>
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] new record-route text!
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 02:13:00 -0500



 

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@exchange.microsoft.com]
> Sent: Tuesday, January 02, 2001 1:47 PM
> To: Henning Schulzrinne; Jonathan Rosenberg
> Cc: sip@lists.bell-labs.com
> Subject: RE: [SIP] new record-route text!
> 
> 
> I am concerned with the mandatory aspect of the record-route 
> parameter.
> Part of the beauty of SIP is that it can operate in a strict 
> end-to-end
> mode; the record-route procedure allows intermediaries to arbitrarily
> break that end-to-end property. I understand that this could be useful
> sometimes, for some crazy network configurations,

Er, I suspect these "crazy" cases are likely to be the norm (i.e., presence
of NATs and firewalls).

>  but if we make this
> mandatory we should have at a minimum an escape hatch. 

I want to make sure that a UA can be deployed in many different network
configurations. There is nothing that forces a network operator to
record-route, and thus provide direct end to end signaling as you would
like. However, there are operators that will want to, and need to,
record-route, and I want to make sure any UA can operate under these
conditions.


More precisely,
> the syntax of the contact header should allow us to 
> distinguish between
> two cases:
> 1) a contact address that can only be reached through the recorded
> route,
> 2) a contact address that can be accessed directly.
> I would contend that, if we don't want to recycle the SIP spec to the
> proposed standard spec, the latter should be the default, as 
> the strict
> record route requirement breaks compatibility with the original
> specification.

I believe that not having record-route be mandatory in rfc2543 is actually a
bug, and so fixing it is part of what happens in the evolution to draft. THe
reason I think its broken is that there will be firewalls and ALGs that need
to see all the signaling in order to open pinholes and do NAT bindings.
These devices need to record route, and if clients don't follow that
record-routing, the call will fail. 

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 02:32:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29908
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 02:32:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 929394434C; Thu,  4 Jan 2001 01:33:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 9F7B044344
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 01:32:24 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA25304;
	Thu, 4 Jan 2001 02:34:52 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBPT0>; Thu, 4 Jan 2001 02:29:19 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAFA4@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Billy Biggs'" <billy@billybiggs.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: SIP List <sip@lists.bell-labs.com>
Subject: RE: RR for non-INVITE call legs (was Re: [SIP] new record-route t
	 ext!)
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 02:29:14 -0500



 

> -----Original Message-----
> From: Billy Biggs [mailto:billy@billybiggs.com]
> Sent: Tuesday, January 02, 2001 12:53 AM
> To: Jonathan Rosenberg
> Cc: SIP List
> Subject: Re: RR for non-INVITE call legs (was Re: [SIP] new 
> record-route
> t ext!)
> 
> 
> Jonathan Rosenberg (jdrosen@dynamicsoft.com):
> 
> > >   Your proposal seems to be that any request other than INVITE
> > > cannot create a call leg, and that the NOTIFY be sent strictly to
> > > the Contact address, not follow the Route, and reset the tags.
> > 
> > No, no. THat is not what I had in mind. I believe it is fine to
> > record-route for any requests that do explicitly establish some kind
> > of session state with a well defined duration. [...]
> 
>   Thanks, that makes me feel better. :)     However:
> 
> > I would say:
> > 
> >    The record-routing mechanism only applies to methods 
> that establish
> >    some kind of session state. For the methods defined in this
> >    specification, that is only the \INVITE method. As such, 
> inserting
> >    a \header{Record-Route} into \REGISTER, \OPTIONS, 
> \CANCEL, \ACK, or
> >    \BYE is {\NOTALLOWED}. Extensions that define new methods {\MUST}
> >    state whether requests with those methods can be record-routed.
> 
>   To get through our firewall, we have a proxy set to 
> Record-Route every
> message with 'sip:proxy.address' and not keep any state.  This gives
> immediate compatibility with any new extensions that need to work
> through a firewall, such as SUBSCRIBE/NOTIFY.

Well, you shouldn't expect for those record-routes to be reflected or used
except in the methods that they are supposed to be present in.

> 
>   So, I would rather:
> 
>     [...] Extensions that define new methods {\MUST} state whether
>     requests with those methods should be record-routed.
>     Implementations {\MAY} choose to add a record-route to unknown
>     methods.

If you are saying that a UA shouldn't barf on a record-route where one
shouldn't normally be, I'll agree. If you are saying that a UA should be
able to reflect record-routes in methods where they are not supposed to be,
I would disagree.


> 
> > > RR for non-INVITE call legs and non-INVITE requests, part 2:
> > > 
> > >   RR/Route must be allowed for non-INVITE requests within a call,
> > >   such as REFER. 
> > 
> > Route, yes. Record-Route, no. What is the point of 
> record-routing refer
> > mid-call? [...]
> > 
> > > This of course makes the logic really weird, since the 
> behavior for
> > > non-INVITE requests outside of a leg is different than 
> those within.
> > 
> > How does this follow?
> 
>   If you don't know anything about NEWMETHOD and you statelessly add
> Record-Routes, then you would want to do the same whether its 
> a mid-call
> NEWMETHOD or an initial NEWMETHOD.

As above, if by "allowed" you mean that a UA shouldn't barf, but will
otherwise ignore it when it shouldn't be there, I'll agree. I added some
text indicating that.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 02:49:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00023
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 02:49:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4DC2644337; Thu,  4 Jan 2001 01:50:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id D4E7844336
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 01:49:15 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA25353;
	Thu, 4 Jan 2001 02:44:16 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBP4L>; Thu, 4 Jan 2001 02:38:43 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAFA5@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Piotr S. Kossowski'" <P.Kossowski@elka.pw.edu.pl>,
        SIP discussion list <sip@lists.bell-labs.com>
Subject: RE: [SIP] State transition diagram for INVITE
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-2"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 02:38:41 -0500



 

> -----Original Message-----
> From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl]
> Sent: Sunday, December 17, 2000 6:00 PM
> To: SIP discussion list
> Subject: [SIP] State transition diagram for INVITE
> 
> 
> Dear All,
> 
> I'm a bit confused after long studying of Figure 12 of the 2543 spec.
> There is State Machine for INVITE method there.

Actually, you are talking about rfc2543bis.


> I'm especially interested in two states: CONFIRMED and COMPLETED.
> 
> Please, correct me if I am wrong:
> Being in FAILURE or SUCCESS we can proceed to COMPLETED under one
> condition: 32 second of inactivity (no requests from UAC).
> Within 32 s. the state machine is waiting for ACK. If no ACK, 
> it probably
> means that something must have happend to UAC, and "for sure" 
> the Call is
> lost. 

Yes.

> So, COMPLETED state is common for FAILURE and SUCCESS and simply
> means "forget this call". 

The state machine is transactional; it does not relate to call state. 

Hovewer, if ACK for SUCCESS call (200 OK was
> sent)
> appears State Machine procceds to CONFIRMED state and then 
> ALWAYS after
> 32 s. to the COMPLETED (call established, transaction successfully
> finalized)
> Thus, My question is:
> 
> 1. Does COMPLETED mean realy two states: either COMPLETED_SUCCESS or
>   COMPLETED_FAILURE? 
>   If yes, Maybe lack of ACK witihin 32s in SUCCESS state 
> allows machine to 
>   procceed to COMPLETED_SUCCESS ?!

As I said, the state machine is for the INVITE *transaction*; it is not a
call state machine. The transaction is completed, for better or worse, if
either we got an ACK and everything was OK, or no ACK ever arrived.

> 
> 2. What for is CONFIRMED state in fact ? No action is 
> generated on ACK 
>    in this state, and no (?) "call specific variables" are changed on 
>    "32s" transtition to COMPLETED.

The state is to handle any additional ACKs that may be in the network. It
simply ignores them, as opposed to the case where an ACK arrives for an
unknown transaction, which might be logged as an error in a real system.

> 
> 
> And my last issue. Let's consider the following scenario:
> 
> We are currently in SUCCCESS state. So, we are waiting for 
> ACK. Sometimes, 
> we can  receive a lost INVITE - we treat it as a 
> retransmission and we 
> send, what  we have just sent - 200 OK.
> But, according to 4.2.1 (INVITE description), we must regard this 
> transaction as COMPLETED or, at least, we are not allowed to 
> response with
> "400 Bad Request" if we have just received another INVITE (re-INVITE).

If a new INVITE arrives, it is a new transaction, and thus a new state
machine. 
Again, your confusion stems from trying to interpret this diagram as a call
state machine as opposed to a transaction state machine.

> If this is true, such re-INVITE should invoke new instance of state
> machine.
> (or something else should happend, correct me)

Yes.

> For one call, we have now two state machines. Let the second machine
> work. Meanwhile, 32s timeout expired and the first machine transited
> to COMPLETED. Beacause I don't know (as mentioned above) what 
> COMPLETED
> really means, my question is: what may (should, must) happen then:
> - Behaviour the first machine is irrelevant ("the newest" machine
>   "hide" all the previous)
> - The second machine should be stopped, because the call was 
> broken down.
>   The call is being destroyed.
> - something else ?

The call state processing is separate. If I get an INVITE, and while
waiting, get and reject a re-INVITE, and then accept the initial INVITE, the
call is active.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 06:55:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01871
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 06:55:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1483744337; Thu,  4 Jan 2001 05:56:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb3.rediffmail.com (unknown [202.54.124.148])
	by lists.bell-labs.com (Postfix) with SMTP id 2365C44336
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 05:55:47 -0500 (EST)
Received: (qmail 5574 invoked by uid 510); 4 Jan 2001 11:54:05 -0000
Message-ID: <20010104115405.5573.qmail@mailweb3.rediffmail.com>
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
From: "Deepak  Mohan" <deepakwarrier@rediffmail.com>
Content-ID: <Thu_Jan__4_17_24_05_IST_2001_0@mailweb3.rediffmail.com>
Content-type: text/plain
Content-Transfer-Encoding: 7bit
Subject: [SIP] "method" parameter in "contact"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 4 Jan 2001 11:54:05 -0000
Content-Transfer-Encoding: 7bit

In which request/response will the "contact" header have the "method" parameter, and what is the use?

Thanks,
Deepak

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 07:05:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01965
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 07:05:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 23D3544341; Thu,  4 Jan 2001 06:06:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb7.rediffmail.com (unknown [202.54.124.152])
	by lists.bell-labs.com (Postfix) with SMTP id CC1A144340
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 06:05:58 -0500 (EST)
Received: (qmail 3052 invoked by uid 510); 4 Jan 2001 12:04:11 -0000
Message-ID: <20010104120411.3051.qmail@mailweb7.rediffmail.com>
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
From: "Deepak  Mohan" <deepakwarrier@rediffmail.com>
Content-ID: <Thu_Jan__4_17_34_11_IST_2001_0@mailweb7.rediffmail.com>
Content-type: text/plain
Content-Transfer-Encoding: 7bit
Subject: [SIP] Canceling BYE
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 4 Jan 2001 12:04:11 -0000
Content-Transfer-Encoding: 7bit

The draft-ietf-sip-rfc2543bis-02 does not say anything about a CANCEL being used to cancel a BYE. Should this be allowed? I don't think very many protocols allow a 'Release' message to be canceled.

Thanks,
Deepak

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 07:34:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02602
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 07:34:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3F0AE4433B; Thu,  4 Jan 2001 06:35:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb3.rediffmail.com (unknown [202.54.124.148])
	by lists.bell-labs.com (Postfix) with SMTP id 9BB0344337
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 06:34:22 -0500 (EST)
Received: (qmail 1024 invoked by uid 510); 4 Jan 2001 12:32:52 -0000
Message-ID: <20010104123252.1023.qmail@mailweb3.rediffmail.com>
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
From: "Vijeth  D" <vijethd@rediffmail.com>
Content-ID: <Thu_Jan__4_18_02_52_IST_2001_0@mailweb3.rediffmail.com>
Content-type: text/plain
Content-Transfer-Encoding: 7bit
Subject: [SIP] SIP grammar doubt.
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 4 Jan 2001 12:32:52 -0000
Content-Transfer-Encoding: 7bit

Hi,

 I am referrring to draft-ietf-sip-rfc2543bis-01.abnf for the sip message grammar. The authorization and the WWW Auth. header fields have been specified as using PGP based encryption.But RFC says that SIP can support both basic and digest schemes of HTTP. 
Is it still as the RFC specifies or is it that authorization and www auth headers can have only PGP based encryption.

regards. 

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 09:41:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05722
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 09:41:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B85E44433B; Thu,  4 Jan 2001 08:42:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 5F76D4433A
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 08:41:11 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA22335;
	Thu, 4 Jan 2001 09:40:56 -0500 (EST)
Message-ID: <3A548B79.7F8AD105@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Christian Huitema'" <huitema@exchange.microsoft.com>,
        sip@lists.bell-labs.com
Subject: Re: [SIP] new record-route text!
References: <B65B4F8437968F488A01A940B21982BF9AAFA3@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 04 Jan 2001 09:40:57 -0500
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 

> 
> I believe that not having record-route be mandatory in rfc2543 is actually a
> bug, and so fixing it is part of what happens in the evolution to draft. THe
> reason I think its broken is that there will be firewalls and ALGs that need
> to see all the signaling in order to open pinholes and do NAT bindings.
> These devices need to record route, and if clients don't follow that
> record-routing, the call will fail.
> 

I don't think this is true. In almost all cases, outbound proxies,
without RR, can handle firewalling and NATs.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 09:43:21 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05754
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 09:43:20 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A0E124434A; Thu,  4 Jan 2001 08:42:08 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by lists.bell-labs.com (Postfix) with ESMTP id ECD854433A
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 08:41:32 -0500 (EST)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257)
 id <0G6N00B017GOWP@firewall.mcit.com> for sip@lists.bell-labs.com; Thu,
 4 Jan 2001 14:41:12 +0000 (GMT)
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0G6N00B1N7GOIX@firewall.mcit.com>; Thu,
 04 Jan 2001 14:41:12 +0000 (GMT)
Received: from CONVERSION-DAEMON by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 id <0G6N001017GNTK@pmismtp02.wcomnet.com>; Thu,
 04 Jan 2001 14:41:12 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with SMTP id <0G6N001017GNTG@pmismtp02.wcomnet.com>;
 Thu, 04 Jan 2001 14:41:11 +0000 (GMT)
Received: from hsinnreich ([166.46.20.52])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with SMTP id <0G6N00MAY7G7RC@pmismtp02.wcomnet.com>; Thu,
 04 Jan 2001 14:40:56 +0000 (GMT)
From: Henry Sinnreich <Henry.Sinnreich@wcom.com>
In-reply-to: <4.3.2.7.2.20000724065902.00d2fa60@webhost.tactical-sw.com>
To: SIP Forum List <owner-discussion@listserver.wineasy.se>,
        sip@lists.bell-labs.com
Message-id: <NEBBLDFFKGAJDPBENMDNCEFLDGAA.Henry.Sinnreich@wcom.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Subject: [SIP] Book on SIP!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 04 Jan 2001 08:41:08 -0600
Content-Transfer-Encoding: 7bit

SIP: Understanding the Session Initiation Protocol by Alan B. Johnston,
Artech House 2001
ISBN 1-58053-168-7

http://www.amazon.com/exec/obidos/ASIN/1580531687/qid%3D978450813/106-333021
6-4182046

Henry


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 10:33:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07290
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 10:33:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A26364433A; Thu,  4 Jan 2001 09:34:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web10301.mail.yahoo.com (web10301.mail.yahoo.com [216.136.130.79])
	by lists.bell-labs.com (Postfix) with SMTP id C624944336
	for <SIP@lists.bell-labs.com>; Thu,  4 Jan 2001 09:33:15 -0500 (EST)
Message-ID: <20010104153304.48259.qmail@web10301.mail.yahoo.com>
Received: from [203.200.4.212] by web10301.mail.yahoo.com; Thu, 04 Jan 2001 07:33:04 PST
From: james jack <sipjames@yahoo.com>
To: SIP@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] A foolish idea
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 07:33:04 -0800 (PST)

Dear All:
  I have foolish idea on Via, for via, On page 57 of
RFC2543bis02, which describes as the following"
" Each subsequent proxy server that sends the request
onwards MUST add its own additional Via field before
any existing Via fields. " It means whether the proxy
to be stateful or stateless must insert via
information in the Via header.
    In my opinion, I think for stateless proxy, there
is no need to insert it's via information in the Via
header. thus can save the time for parsing the SIP
message. Then stateless proxy received one request
message, there is no need for it to parse the whole
message, only parse the Request-Line,using DNS to 
get the next hop of the request?
    But this idea also has some disadvantage, for
example, if not parsed fully, how can the stateless
proxy check the location information?
   Thanks in advance, please give your idea?
                                    Yours: james



__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 10:45:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07739
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 10:45:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EFFB04434F; Thu,  4 Jan 2001 09:46:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web10308.mail.yahoo.com (web10308.mail.yahoo.com [216.136.130.86])
	by lists.bell-labs.com (Postfix) with SMTP id 3BF334434E
	for <SIP@lists.bell-labs.com>; Thu,  4 Jan 2001 09:45:48 -0500 (EST)
Message-ID: <20010104154536.36021.qmail@web10308.mail.yahoo.com>
Received: from [203.200.4.212] by web10308.mail.yahoo.com; Thu, 04 Jan 2001 07:45:36 PST
From: james jack <sipjames@yahoo.com>
To: SIP@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] Some consultation on Via
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 07:45:36 -0800 (PST)

Dear All:
   I have one question to consult.
   Supposed a stateless proxy P received the following

response ( assume the domain of proxy P is
pp.pcom.com,
the listening port is 5700)
 "  SIP/2.0 200 OK
   Via: SIP/2.0/UDP ss1.wcom.com:5060;branch=2d4790.1
   Via: SIP/2.0/UDP
fwp1.wcom.com:5060;branch=9471385739578.1
   Via: SIP/2.0/UDP here.com:5060
   Record-Route:
<sip:UserB@there.com;maddr=ss1.wcom.com>,
    <sip:UserB@there.com;maddr=fwp1.wcom.com>
   From: BigGuy <sip:UserA@here.com>
   To: LittleGuy <sip:UserB@there.com>;tag=314159
   Call-ID: 12345600@here.com
   CSeq: 1 INVITE
   Contact: LittleGuy <sip:UserB@there.com>
   Content-Type: application/sdp
   Content-Length: 147

   v=0
   o=UserB 2890844527 2890844527 IN IP4 there.com
   s=Session SDP
   c=IN IP4 110.111.112.113
   t=0 0
   m=audio 3456 RTP/AVP 0
   a=rtpmap:0 PCMU/8000"
  The above message,where the Via information can't
match the information of that in Proxy P, Under this
situation, will P discard it or continue upstream it?

  What's more, if this is stateful proxy, and the
callleg can match the stored information, then 
what would happen?
  You are welcome to give your suggestion and 
opinion?
  I am looking foreard to getting your reponse as soon
as possible!
  Best Regards!
                yours: James


__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 11:08:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08487
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 11:08:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3CB3F44337; Thu,  4 Jan 2001 10:09:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id D269C44336
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 10:08:59 -0500 (EST)
Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f04G8cK23276;
	Thu, 4 Jan 2001 10:08:39 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f04G5K417412;
	Thu, 4 Jan 2001 10:05:20 -0600 (CST)
Received: from ericsson.com (pc050188.exu.ericsson.se [138.85.50.188]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA26845; Thu, 4 Jan 2001 10:08:36 -0600 (CST)
Message-ID: <3A54A015.5040804@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Deepak Mohan <deepakwarrier@rediffmail.com>
Cc: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
Subject: Re: [SIP] Canceling BYE
References: <20010104120411.3051.qmail@mailweb7.rediffmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 04 Jan 2001 10:08:53 -0600
Content-Transfer-Encoding: 7bit

Yes, this should be allowed. The more important question
is what it means. Since CANCEL is just a suggestion, I
would not count on it having *any* effect on the outcome
of the BYE transaction. ie. it may be effectively ignored.

/sean

Deepak Mohan wrote:

> The draft-ietf-sip-rfc2543bis-02 does not say anything about a CANCEL being used to cancel a BYE. Should this be allowed? I don't think very many protocols allow a 'Release' message to be canceled.
> 
> Thanks,
> Deepak
> 
> _____________________________________________________
> Chat with your friends as soon as they come online. Get Rediff Bol at
> http://bol.rediff.com
> 
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 12:09:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10393
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 12:09:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 87DF644337; Thu,  4 Jan 2001 11:10:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by lists.bell-labs.com (Postfix) with ESMTP id 854E644336
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 10:20:50 -0500 (EST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id IAA22485;
	Thu, 4 Jan 2001 08:20:04 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA20693; Thu, 4 Jan 2001 08:20:04 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14932.41651.858353.383485@thomasm-u1.cisco.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Christian Huitema'" <huitema@exchange.microsoft.com>,
        Henning Schulzrinne <hgs@cs.columbia.edu>, sip@lists.bell-labs.com
Subject: RE: [SIP] new record-route text!
In-Reply-To: <B65B4F8437968F488A01A940B21982BF9AAFA3@DYN-EXCH-001.dynamicsoft.com>
References: <B65B4F8437968F488A01A940B21982BF9AAFA3@DYN-EXCH-001.dynamicsoft.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 08:20:03 -0800 (PST)
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg writes:
 > > From: Christian Huitema [mailto:huitema@exchange.microsoft.com]
 > > I am concerned with the mandatory aspect of the record-route 
 > > parameter.
 > > Part of the beauty of SIP is that it can operate in a strict 
 > > end-to-end
 > > mode; the record-route procedure allows intermediaries to arbitrarily
 > > break that end-to-end property. I understand that this could be useful
 > > sometimes, for some crazy network configurations,
 > 
 > Er, I suspect these "crazy" cases are likely to be the norm (i.e., presence
 > of NATs and firewalls).

Jonathan,

I respect your desire to get this to play as well
as to be expected with fog machines, but if it
comes at the cost of making a mess out of a clear,
sunny net I have serious problems. Assuming you
haven't already drank the kool-aid, let's be
careful here; record route is a sometimes useful,
but unwieldy and unreliable tool which should be
used as little as possible. The preface text of
RR ought to be "If you think you need it, you
probably don't. Think again."

 > >  but if we make this
 > > mandatory we should have at a minimum an escape hatch. 
 > 
 > I want to make sure that a UA can be deployed in many different network
 > configurations. There is nothing that forces a network operator to
 > record-route, and thus provide direct end to end signaling as you would
 > like. However, there are operators that will want to, and need to,
 > record-route, and I want to make sure any UA can operate under these
 > conditions.

Doesn't the proxy which is controlling the
firewall already need to protect itself from
either non-compliant UA's, or, say, UA's that
crash mid-call? Ie, the proxy only expecting to
see a BYE to close the pinhole is already in
trouble due to entropy? If so, might not a better
route to rely on soft state on the firewall
completely instead of trying to rely on the
signaling plane?

If so, I think that Christian's sense is right
insofar as it underscores to the proxy that the
UA _may_ respect the RR, but ultimately it cannot
be counted on to do so for either policy or 
entomological reasons.

		Mike

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 12:11:21 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10451
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 12:11:21 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EB42244359; Thu,  4 Jan 2001 11:10:09 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by lists.bell-labs.com (Postfix) with ESMTP id 4178344336
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 10:57:19 -0500 (EST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id IAA23249;
	Thu, 4 Jan 2001 08:56:33 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA20697; Thu, 4 Jan 2001 08:56:32 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14932.43840.845104.486683@thomasm-u1.cisco.com>
To: Jon.Peterson@Level3.com
Cc: huitema@exchange.microsoft.com, hgs@cs.columbia.edu,
        jdrosen@dynamicsoft.com, sip@lists.bell-labs.com
Subject: RE: [SIP] new record-route text!
In-Reply-To: <6384220893BCD411BDFE0008C791B79C232CA6@N0228IDC1.oss.level3.com>
References: <6384220893BCD411BDFE0008C791B79C232CA6@N0228IDC1.oss.level3.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 08:56:32 -0800 (PST)
Content-Transfer-Encoding: 7bit

Jon.Peterson@Level3.com writes:
 > This would just encourage the use of B2BUAs by service providers who want to
 > retain control over the call (for applications, for billing, or other insane
 > and nefarious purposes). Nothing can prevent the administration of a proxy
 > in the chain of signaling (a chain ultimately initiated by the user) from
 > forcing all subsequent requests for a call to go through its systems - that
 > is their architectural perogative. B2BUAs may, however, break some
 > end-to-end mechanisms and introduce further latency to the signaling.

   I suspect that Jonathan is right in maintaining that
   the vast majority of rationale for RR is to deal with
   firewall/NAT's. Once you do the latter you've
   already broken e2e transparency, so thinking
   about it in terms of a B2BUA is probably
   actually the _right_ thing to do. In fact, I'd
   say that if the proxy needs to in some way
   control the session plane (ie, signal a
   firewall to open/close a hole), you've
   crossed the line: it's an UA. It doesn't
   matter whether the session actually traverses
   it because that's nothing more than a
   decomposed UA in disguise. And sure ALG's 
   cause lots of trouble -- but let's not
   pretend that we can change those issues by
   artfully maneuvering definitions to obscure
   the fact that it does, indeed, quack.

	    Mike
   

 > 
 > Jon Peterson
 > Level(3) Communications
 > 
 > -----Original Message-----
 > From: Christian Huitema [mailto:huitema@exchange.microsoft.com]
 > Sent: Tuesday, January 02, 2001 11:47 AM
 > To: Henning Schulzrinne; Jonathan Rosenberg
 > Cc: sip@lists.bell-labs.com
 > Subject: RE: [SIP] new record-route text!
 > 
 > 
 > I am concerned with the mandatory aspect of the record-route parameter.
 > Part of the beauty of SIP is that it can operate in a strict end-to-end
 > mode; the record-route procedure allows intermediaries to arbitrarily
 > break that end-to-end property. I understand that this could be useful
 > sometimes, for some crazy network configurations, but if we make this
 > mandatory we should have at a minimum an escape hatch. More precisely,
 > the syntax of the contact header should allow us to distinguish between
 > two cases:
 > 1) a contact address that can only be reached through the recorded
 > route,
 > 2) a contact address that can be accessed directly.
 > I would contend that, if we don't want to recycle the SIP spec to the
 > proposed standard spec, the latter should be the default, as the strict
 > record route requirement breaks compatibility with the original
 > specification.
 > 
 > -- Christian Huitema
 > 
 > _______________________________________________
 > SIP mailing list
 > SIP@lists.bell-labs.com
 > http://lists.bell-labs.com/mailman/listinfo/sip
 > 
 > _______________________________________________
 > SIP mailing list
 > SIP@lists.bell-labs.com
 > http://lists.bell-labs.com/mailman/listinfo/sip
 > 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 12:23:04 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10720
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 12:23:03 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BE18444359; Thu,  4 Jan 2001 11:23:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from guardian1.tlv.radvision.com (unknown [212.143.185.30])
	by lists.bell-labs.com (Postfix) with ESMTP id 13FB244337
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 11:22:02 -0500 (EST)
Received: from nt-mail.tlv.radvision.com ([172.20.2.100])
          by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3
          release 223 ID# 0-0U10L2S100V35) with ESMTP id com
          for <sip@lists.bell-labs.com>; Thu, 4 Jan 2001 20:19:27 +0200
Received: by nt-mail.tlv.radvision.com with Internet Mail Service (5.5.2650.21)
	id <C2B6B3ZR>; Thu, 4 Jan 2001 19:23:18 +0200
Message-ID: <E09383987EE5D3119F2E0008C7097728014D74BB@nt-mail.tlv.radvision.com>
From: Itamar Gilad <ItamarG@tlv.radvision.com>
To: "'SIP List'" <sip@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="WINDOWS-1255"
Subject: [SIP] is SIP backward compatible?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 19:23:17 +0200

Everybody,
I'm looking for some guidance in regard to the backward compatibility of
SIP.  From following the mailing list and relevant events I know that an
effort is made not to break existing implementations, yet a pure RFC2543
might have interop problems with a pure bis-02 implementation because of
some of the changes made.  My questions:
* What are the rules that determine this?  
* Are the compatibility-breaking changes about to stop once bis-02 goes RFC?
Anytime?
* Is there some sort of general IETF guideline to this matter?

Thanks,

Itamar Gilad
RADVision					24 Raul Wallenberg St.
itamarg@tlv.radvision.com		Building D
tel: +972 3 7659938			Tel-Aviv 69719
fax: +972 3 6442903			Israel	


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 13:04:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11524
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 13:04:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CE3FE4434F; Thu,  4 Jan 2001 12:05:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 02BA344337
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 12:04:21 -0500 (EST)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257)
 id <0G6N00001GUEBF@firewall.mcit.com> for sip@lists.bell-labs.com; Thu,
 4 Jan 2001 18:03:50 +0000 (GMT)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0G6N00M7MGUDOU@firewall.mcit.com>; Thu,
 04 Jan 2001 18:03:50 +0000 (GMT)
Received: from CONVERSION-DAEMON by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 id <0G6N00D01GUDG1@dgismtp01.wcomnet.com>; Thu,
 04 Jan 2001 18:03:49 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0G6N00D01GUDFY@dgismtp01.wcomnet.com>;
 Thu, 04 Jan 2001 18:03:49 +0000 (GMT)
Received: from hsinnreich ([166.35.226.44])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with SMTP id <0G6N00B51GTPME@dgismtp01.wcomnet.com>; Thu,
 04 Jan 2001 18:03:34 +0000 (GMT)
From: Henry Sinnreich <Henry.Sinnreich@wcom.com>
Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
In-reply-to: <Roam.SIMC.2.0.6.978476425.10317.pcalhoun@nasnfs>
To: Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: Michael Thomas <mat@cisco.com>, SIP List <sip@lists.bell-labs.com>,
        C.T.A.M.deLaat@phys.uu.nl, jrv@interlinknetworks.com
Message-id: <NEBBLDFFKGAJDPBENMDNGEGIDGAA.Henry.Sinnreich@wcom.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 04 Jan 2001 12:03:48 -0600
Content-Transfer-Encoding: 7bit

>We are only trying to provide the infrastructure
>required to support
>them.

There have been a number of I-Ds on this list from people working for
various carriers and I suggest vendors to look at them, such as from AT&T,
L3, Telia and WorldCom in alphabetical order, and others.

One of the papers mentioned here is
http://ietf.org/internet-drafts/draft-gross-cops-sip-00.txt

and it is clearly focused (we hope) on the POLICY SERVER, NOT the AAA
SERVER, in the DIAMETER sense, whose functions are actually absorbed in the
policy server and its constituents, such as directories (personal and
corporate accounts), outsourced policy servers, clearinghouse and other. So
please do not assume that all ISP folks see the AAA server as the center of
the universe...

As for the question why XML/HTTP:

ISP services development and operations costs are minimized by using the
smallest number of protocols and data formats.
HTTP clearly makes it to the top of the short list for transport.
XML has countless tools for dummies (like me) and can be displayed with the
browser and is thus ideal for testing and prototyping in this fast changing
environment. It is has also a large field of applicability. DIAMETER with
its AVP data formats does not have these advantages - may have its place as
mentioned for network access, but is not in the center of the AAA universe
IMHO. Pushing DIAMETER to be the focus of AAA is not convincing.

Henry

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Pat Calhoun
> Sent: Tuesday, January 02, 2001 5:00 PM
> To: Henning G. Schulzrinne
> Cc: Pat Calhoun; Michael Thomas; SIP List
> Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
>
>
>
> >
> > I'm still trying to understand why the act of sending SIP requests is
> > subject to authorization. Will each new UDP port number and service get
> > its own AAA infrastructure? (I can see authorizing resource
> > reservations, but that's completely orthogonal to SIP, as has been
> > discussed here a few times...)
>
> Good question.
>
> The carriers want to control who has access to certain services
> (say *traffic,
> *911, etc.) Also in other cases, they want to get explicit
> authorization for
> certain services, since they will incur a surcharge.
>
> So when a request is received, say an invite to *traffic, a
> request is sent
> off to the AAA server to ensure that the user is authenticated,
> and has access
> to the said service. As far as *traffic is concerned, having traffic
> information in the home network doesn't really do much good when one is
> roaming :)
>
> However, the actual services are still being worked out, and are carrier
> specific. We are only trying to provide the infrastructure
> required to support
> them.
>
> PatC
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 13:49:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12899
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 13:49:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C1F524434E; Thu,  4 Jan 2001 12:50:02 -0500 (EST)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id 2977944337
	for <sip@share.research.bell-labs.com>; Thu,  4 Jan 2001 12:49:24 -0500 (EST)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jan  4 13:46:33 EST 2001
Received: by lists.bell-labs.com (Postfix)
	id A458244380; Thu,  4 Jan 2001 13:34:35 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5])
	by lists.bell-labs.com (Postfix) with SMTP id 2160A4437D
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 13:34:34 -0500 (EST)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id MAA05992; Thu, 4 Jan 2001 12:34:26 -0600
Cc: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id MAA05985; Thu, 4 Jan 2001 12:34:24 -0600
Message-ID: <3A54C226.FAA541A@lucent.com>
From: Vijay Gurbani <vkg@lucent.com>
Organization: Lucent Technologies/Bell Laboratories
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Deepak Mohan <deepakwarrier@rediffmail.com>
Original-CC: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
Subject: Re: [SIP] Canceling BYE
References: <20010104120411.3051.qmail@mailweb7.rediffmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 04 Jan 2001 12:34:14 -0600
Content-Transfer-Encoding: 7bit

Deepak Mohan wrote:
> 
> The draft-ietf-sip-rfc2543bis-02 does not say anything about a CANCEL 
> being used to cancel a BYE. Should this be allowed? I don't think very 
> many protocols allow a 'Release' message to be canceled.

While CANCEL can be used to cancel a pending request (including BYE or
OPTIONS, or even REGISTER), in majority of cases, it is used in conjunction
with an INVITE request.  

If a UAS gets a CANCEL to a non-INVITE request before it has generated a 
final response, the request can effectively be canceled (although, as you
point out, what is the result of CANCEL'ing a BYE -- does that mean that
the session should NOT be torn down?).  If a final response has already been
generated by a UAS and a CANCEL received after that, the CANCEL is basically
a no-op (although the UAS has to 200 OK it).

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 15:44:22 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15674
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 15:44:19 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B7FA744344; Thu,  4 Jan 2001 14:44:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 5E0E544344
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 14:43:41 -0500 (EST)
Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id UAA07641;
	Thu, 4 Jan 2001 20:44:39 GMT
Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Thu, 04 Jan 2001 20:43:16 0000 (GMT)
Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <Z660TWYS>; Thu, 4 Jan 2001 12:43:14 -0800
Message-ID: <4148FEAAD879D311AC5700A0C969E8902D4915@orsmsx35.jf.intel.com>
From: "Gross, Gerhard" <gerhard.gross@intel.com>
To: SIP List <sip@lists.bell-labs.com>
Cc: C.T.A.M.deLaat@phys.uu.nl, jrv@interlinknetworks.com
Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 12:43:01 -0800

Furthermore, concerning

> As for the question why XML/HTTP:

(paraphrasing one of my colleagues):

A major drawback of AVP is that it uses
a binary (non-textual) representation
requiring programmers and the appropriate
programming tools to use and understand it.

XML, on the other hand, is text based and
has DTDs and schemas that allow for its
text constructs to be formally described
(via a data definition language). This
makes it much easier to get a computer to
interpret and parse the data. In the case
of AVPs, there is no formal language for
describing the data, its understood
combinations or groupings, its formats, etc.
Thus, it is viewed by many as an
inferior/ancient way of describing data.
Like using two rocks to try to start a fire.
This makes interoperability much more
difficult and prone to errors.

Gery

        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        X                                         X
        X    Gerhard W. Gross, Ph.D.              X
        X    Intel                                X
        X    2111 NE 25th Ave                     X
        X    Hillsboro, OR 97124-5961, USA        X
        X    Policy Architecture Group            X
        X      - Internet and Communication Lab   X
        X    phone:    (503) 264-6389             X
        X    fax:      (503) 264-3483             X
        X    email:    gerhard.gross@intel.com    X
        X                                         X
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX



> -----Original Message-----
> From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com]
> Sent: Thursday, January 04, 2001 10:04 AM
> To: Pat Calhoun; Henning G. Schulzrinne
> Cc: Michael Thomas; SIP List; C.T.A.M.deLaat@phys.uu.nl;
> jrv@interlinknetworks.com
> Subject: RE: [aboba@internaut.com: Re: [SIP] 
> draft-calhoun-sip-aaa-req]
> 
> 
> >We are only trying to provide the infrastructure
> >required to support
> >them.
> 
> There have been a number of I-Ds on this list from people working for
> various carriers and I suggest vendors to look at them, such 
> as from AT&T,
> L3, Telia and WorldCom in alphabetical order, and others.
> 
> One of the papers mentioned here is
> http://ietf.org/internet-drafts/draft-gross-cops-sip-00.txt
> 
> and it is clearly focused (we hope) on the POLICY SERVER, NOT the AAA
> SERVER, in the DIAMETER sense, whose functions are actually 
> absorbed in the
> policy server and its constituents, such as directories (personal and
> corporate accounts), outsourced policy servers, clearinghouse 
> and other. So
> please do not assume that all ISP folks see the AAA server as 
> the center of
> the universe...
> 
> As for the question why XML/HTTP:
> 
> ISP services development and operations costs are minimized 
> by using the
> smallest number of protocols and data formats.
> HTTP clearly makes it to the top of the short list for transport.
> XML has countless tools for dummies (like me) and can be 
> displayed with the
> browser and is thus ideal for testing and prototyping in this 
> fast changing
> environment. It is has also a large field of applicability. 
> DIAMETER with
> its AVP data formats does not have these advantages - may 
> have its place as
> mentioned for network access, but is not in the center of the 
> AAA universe
> IMHO. Pushing DIAMETER to be the focus of AAA is not convincing.
> 
> Henry
> 
> > -----Original Message-----
> > From: sip-admin@lists.bell-labs.com
> > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Pat Calhoun
> > Sent: Tuesday, January 02, 2001 5:00 PM
> > To: Henning G. Schulzrinne
> > Cc: Pat Calhoun; Michael Thomas; SIP List
> > Subject: Re: [aboba@internaut.com: Re: [SIP] 
> draft-calhoun-sip-aaa-req]
> >
> >
> >
> > >
> > > I'm still trying to understand why the act of sending SIP 
> requests is
> > > subject to authorization. Will each new UDP port number 
> and service get
> > > its own AAA infrastructure? (I can see authorizing resource
> > > reservations, but that's completely orthogonal to SIP, as has been
> > > discussed here a few times...)
> >
> > Good question.
> >
> > The carriers want to control who has access to certain services
> > (say *traffic,
> > *911, etc.) Also in other cases, they want to get explicit
> > authorization for
> > certain services, since they will incur a surcharge.
> >
> > So when a request is received, say an invite to *traffic, a
> > request is sent
> > off to the AAA server to ensure that the user is authenticated,
> > and has access
> > to the said service. As far as *traffic is concerned, having traffic
> > information in the home network doesn't really do much good 
> when one is
> > roaming :)
> >
> > However, the actual services are still being worked out, 
> and are carrier
> > specific. We are only trying to provide the infrastructure
> > required to support
> > them.
> >
> > PatC
> >
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 15:56:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15961
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 15:56:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 461744435E; Thu,  4 Jan 2001 14:57:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id B803E44337
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 14:56:25 -0500 (EST)
Received: from cowboys (IDENT:root@localhost [127.0.0.1])
	by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id DAA22583;
	Fri, 5 Jan 2001 03:02:06 -0600
Message-ID: <007b01c07690$59098c20$ea036e3f@dynamicsoft.com>
From: "Dean Willis" <dean.willis@softarmor.com>
To: "Itamar Gilad" <ItamarG@tlv.radvision.com>,
        "'SIP List'" <sip@lists.bell-labs.com>
References: <E09383987EE5D3119F2E0008C7097728014D74BB@nt-mail.tlv.radvision.com>
Subject: Re: [SIP] is SIP backward compatible?
MIME-Version: 1.0
Content-Type: text/plain;
	charset="WINDOWS-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 14:53:09 -0600
Content-Transfer-Encoding: 7bit


RFC 2026 says:

"A specification may be (indeed, is likely to be) revised as it  advances
through the standards track.  At each stage, the IESG shall determine the
scope and significance of the revision to the specification, and, if
necessary and appropriate, modify the recommended action.  Minor revisions
are expected, but a significant revision may require that the specification
accumulate more experience at its current maturity level before progressing.
Finally, if the specification has been changed very significantly, the IESG
may recommend that the revision be treated as a new document, reentering the
standards track at the beginning."

In other words: we try not to break compatibility, but sometimes find that a
protocol is already broken and needs fixing. Change is not mandatory.
Neither is survival ;-).

Generally speaking the rate of change declines as a protocol prgresses up
the standards track. There are no absolute rules in this area that I am
aware of.

--
Dean Willis

----- Original Message -----
From: "Itamar Gilad" <ItamarG@tlv.radvision.com>
To: "'SIP List'" <sip@lists.bell-labs.com>
Sent: Thursday, January 04, 2001 11:23 AM
Subject: [SIP] is SIP backward compatible?


> Everybody,
> I'm looking for some guidance in regard to the backward compatibility of
> SIP.  From following the mailing list and relevant events I know that an
> effort is made not to break existing implementations, yet a pure RFC2543
> might have interop problems with a pure bis-02 implementation because of
> some of the changes made.  My questions:
> * What are the rules that determine this?
> * Are the compatibility-breaking changes about to stop once bis-02 goes
RFC?
> Anytime?
> * Is there some sort of general IETF guideline to this matter?
>
> Thanks,
>
> Itamar Gilad
> RADVision 24 Raul Wallenberg St.
> itamarg@tlv.radvision.com Building D
> tel: +972 3 7659938 Tel-Aviv 69719
> fax: +972 3 6442903 Israel
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 15:58:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15975
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 15:58:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 75EE744369; Thu,  4 Jan 2001 14:59:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail15a.boca15-verio.com (unknown [208.55.91.57])
	by lists.bell-labs.com (Postfix) with SMTP id 974BC44337
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 14:58:25 -0500 (EST)
Received: from www.snowshore.com (128.241.144.247)
	by mail15a.boca15-verio.com (RS ver 1.0.58s) with SMTP id 06406185
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 15:58:01 -0500 (EST)
From: "Eric Burger" <eburger@snowshore.com>
To: <sip@lists.bell-labs.com>
Message-ID: <NEBBLACLCLHMJBCAJGOEGEHPCHAA.eburger@snowshore.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-Loop-Detect: 1
Subject: [SIP] SIP App Components
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 15:58:05 -0500
Content-Transfer-Encoding: 7bit

The SIP App Components infrastructure assumes that the SIP UA's understand
multipart MIME body parts.  This is a MAY in bis 02 (Section 8.2).

Is it safe to assume that the current SIP infrastructure won't choke on SIP
INVITES and potentially responses with multipart MIME, instead of
application/sdp, body parts?


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 16:20:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16353
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 16:20:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3469F4435D; Thu,  4 Jan 2001 15:21:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id F0E9E44357
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 15:20:54 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18545;
	Thu, 4 Jan 2001 13:20:41 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA26411;
	Thu, 4 Jan 2001 13:20:40 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA04515;
	Thu, 4 Jan 2001 13:20:33 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Reply-To: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
To: "Gross, Gerhard" <gerhard.gross@intel.com>
Cc: SIP List <sip@lists.bell-labs.com>, C.T.A.M.deLaat@phys.uu.nl,
        jrv@interlinknetworks.com
In-Reply-To: "Your message with ID" <4148FEAAD879D311AC5700A0C969E8902D4915@orsmsx35.jf.intel.com>
Message-ID: <Roam.SIMC.2.0.6.978643022.17182.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 4 Jan 2001 13:17:02 -0800 (PST)

> Furthermore, concerning
> 
> > As for the question why XML/HTTP:
> 
> (paraphrasing one of my colleagues):
> 
> A major drawback of AVP is that it uses
> a binary (non-textual) representation
> requiring programmers and the appropriate
> programming tools to use and understand it.
> 
> XML, on the other hand, is text based and
> has DTDs and schemas that allow for its
> text constructs to be formally described
> (via a data definition language). This
> makes it much easier to get a computer to
> interpret and parse the data. In the case
> of AVPs, there is no formal language for
> describing the data, its understood
> combinations or groupings, its formats, etc.
> Thus, it is viewed by many as an
> inferior/ancient way of describing data.
> Like using two rocks to try to start a fire.
> This makes interoperability much more
> difficult and prone to errors.
> 
As much as I appreciate these statements that have no
foundation, and are purely religious in nature, I would
like to state that the RADIUS protocol does in fact
have an excellent history of interoperability, with
countless implementations deployed from many vendors. It's
countless problems have nothing to do with the fact that it is,
or not, binary.

btw, Mobile IP, L2TP, PPP, and many are other non text
based protocols, have have a high degree of interoperability.
There are plenty of interoperability reports available
for people to read, should they feel so inclined.

Now that we have diverged sufficiently from the original
intent of the I-D, perhaps we can better concentrate on
what the actual requirements are, and leave protocol bashing
and comparisons until the time when we have requirements to
compare them against?

PatC


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 17:54:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17809
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 17:54:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 23C9644337; Thu,  4 Jan 2001 16:55:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net [208.37.18.67])
	by lists.bell-labs.com (Postfix) with ESMTP id 62BA844336
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 16:54:42 -0500 (EST)
Received: from matt.ipverse.com (lsanca1-ar5-208-222.dsl.gtei.net [4.33.208.222]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id ZV8K8DYH; Thu, 4 Jan 2001 14:54:31 -0800
Message-Id: <5.0.2.1.2.20010104145214.02157ec0@pop3.ipverse.com>
X-Sender: matt@ipverse.com@pop3.ipverse.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
To: "Gross, Gerhard" <gerhard.gross@intel.com>,
        SIP List <sip@lists.bell-labs.com>
From: Matt Holdrege <matt@ipverse.com>
Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
In-Reply-To: <4148FEAAD879D311AC5700A0C969E8902D4915@orsmsx35.jf.intel.c
 om>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 04 Jan 2001 14:54:27 -0800

At 12:43 PM 1/4/2001, Gross, Gerhard wrote:
>Furthermore, concerning
>
> > As for the question why XML/HTTP:
>
>(paraphrasing one of my colleagues):
>
>A major drawback of AVP is that it uses
>a binary (non-textual) representation
>requiring programmers and the appropriate
>programming tools to use and understand it.

Just a nit of mine, but I really hate it when we have to sacrifice quality 
because we're worried about programmers who are inexperienced. Let them go 
to school and learn binary and let the end-users have what they need. There 
are plenty of coders who can handle binary just fine.

I'm not against XML, rather I'm in favor of it. But let's not use the above 
as an excuse.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan  4 20:24:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19223
	for <sip-archive@odin.ietf.org>; Thu, 4 Jan 2001 20:24:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B277844337; Thu,  4 Jan 2001 19:25:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 445D944336
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 19:24:11 -0500 (EST)
Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f051NxK00873;
	Thu, 4 Jan 2001 19:23:59 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f051NxI20100;
	Thu, 4 Jan 2001 19:23:59 -0600 (CST)
Received: from ericsson.com (pc050188.exu.ericsson.se [138.85.50.188]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA20955; Thu, 4 Jan 2001 19:23:58 -0600 (CST)
Message-ID: <3A55222C.80709@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Burger <eburger@snowshore.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP App Components
References: <NEBBLACLCLHMJBCAJGOEGEHPCHAA.eburger@snowshore.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 04 Jan 2001 19:23:56 -0600
Content-Transfer-Encoding: 7bit

Define "choke" :) Multipart MIME should not crash
an implementation that doesn't understand it.
I think you will find that multipart implementations
will become more prevalent as S/MIME catches on and
as more inventive uses of the REGISTER body come
around. [I hope that SIP implementors consider
multipart MIME useful enough to implement it]

/sean

Eric Burger wrote:

> The SIP App Components infrastructure assumes that the SIP UA's understand
> multipart MIME body parts.  This is a MAY in bis 02 (Section 8.2).
> 
> Is it safe to assume that the current SIP infrastructure won't choke on SIP
> INVITES and potentially responses with multipart MIME, instead of
> application/sdp, body parts?
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 01:16:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24819
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 01:16:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 12B2644337; Fri,  5 Jan 2001 00:17:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb7.rediffmail.com (unknown [202.54.124.152])
	by lists.bell-labs.com (Postfix) with SMTP id C5F1244336
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 00:16:36 -0500 (EST)
Received: (qmail 14617 invoked by uid 510); 5 Jan 2001 06:14:47 -0000
Message-ID: <20010105061447.14613.qmail@mailweb7.rediffmail.com>
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
From: "Vijeth  D" <vijethd@rediffmail.com>
Content-ID: <Fri_Jan__5_11_44_46_IST_2001_0@mailweb7.rediffmail.com>
Content-type: text/plain
Content-Transfer-Encoding: 7bit
Subject: [SIP] Also field
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 5 Jan 2001 06:14:47 -0000
Content-Transfer-Encoding: 7bit

Hi,
  The syntax of the also header field is not very clear.
Also = ”Also” ”:” 1# (( name-addr — addr-spec )

First of all a closing parantheses is missing and secondly what is the meaning of a '-' between name-addr and addr-spec?

Thanks,

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 03:06:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07421
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 03:06:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C80B444337; Fri,  5 Jan 2001 02:07:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.speedventures.com (unknown [212.75.74.99])
	by lists.bell-labs.com (Postfix) with ESMTP id 0030044336
	for <SIP@lists.bell-labs.com>; Fri,  5 Jan 2001 02:06:04 -0500 (EST)
Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id ZF96X7P9; Fri, 5 Jan 2001 09:01:14 +0100
From: "Hisham Khartabil" <hisham.khartabil@hotsip.com>
To: "james jack" <sipjames@yahoo.com>, <SIP@lists.bell-labs.com>
Subject: RE: [SIP] Some consultation on Via
Message-ID: <GEEMIMOPEJGBIEGHJBHDIEDICCAA.hisham.khartabil@hotsip.com>
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 IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <20010104154536.36021.qmail@web10308.mail.yahoo.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 5 Jan 2001 10:06:44 +0200
Content-Transfer-Encoding: 7bit

Section 6.46.3 "The first Via header field should indicate the proxy or
client processing this response. If it does not, discard the message"

Regards,
Hisham

-----Original Message-----
From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On
Behalf Of james jack
Sent: Thursday, 4 January 2001 5:46 PM
To: SIP@lists.bell-labs.com
Subject: [SIP] Some consultation on Via

Dear All:
   I have one question to consult.
   Supposed a stateless proxy P received the following

response ( assume the domain of proxy P is
pp.pcom.com,
the listening port is 5700)
 "  SIP/2.0 200 OK
   Via: SIP/2.0/UDP ss1.wcom.com:5060;branch=2d4790.1
   Via: SIP/2.0/UDP
fwp1.wcom.com:5060;branch=9471385739578.1
   Via: SIP/2.0/UDP here.com:5060
   Record-Route:
<sip:UserB@there.com;maddr=ss1.wcom.com>,
    <sip:UserB@there.com;maddr=fwp1.wcom.com>
   From: BigGuy <sip:UserA@here.com>
   To: LittleGuy <sip:UserB@there.com>;tag=314159
   Call-ID: 12345600@here.com
   CSeq: 1 INVITE
   Contact: LittleGuy <sip:UserB@there.com>
   Content-Type: application/sdp
   Content-Length: 147

   v=0
   o=UserB 2890844527 2890844527 IN IP4 there.com
   s=Session SDP
   c=IN IP4 110.111.112.113
   t=0 0
   m=audio 3456 RTP/AVP 0
   a=rtpmap:0 PCMU/8000"
  The above message,where the Via information can't
match the information of that in Proxy P, Under this
situation, will P discard it or continue upstream it?

  What's more, if this is stateful proxy, and the
callleg can match the stored information, then
what would happen?
  You are welcome to give your suggestion and
opinion?
  I am looking foreard to getting your reponse as soon
as possible!
  Best Regards!
                yours: James


__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 03:08:39 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07458
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 03:08:39 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6A4A24433F; Fri,  5 Jan 2001 02:08:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7])
	by lists.bell-labs.com (Postfix) with ESMTP id 2F1CD4433E
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 02:07:36 -0500 (EST)
Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204])
	by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id IAA22475;
	Fri, 5 Jan 2001 08:07:24 GMT
From: Jon.Peterson@Level3.com
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id IAA01490;
	Fri, 5 Jan 2001 08:07:24 GMT
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id <CFJHJHWV>; Fri, 5 Jan 2001 01:09:27 -0700
Message-ID: <6384220893BCD411BDFE0008C791B79C232CC4@N0228IDC1.oss.level3.com>
To: eburger@snowshore.com, sip@lists.bell-labs.com
Subject: RE: [SIP] SIP App Components
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 5 Jan 2001 01:05:54 -0700

As Sean said, multipart MIME shouldn't crash a UA. There is a defined
behavior for a UA that does not support a given MIME type (including
multipart/mixed or what have you) that it receives in a SIP request; namely,
responding with a 415 with an Accept header indicating the MIME types that
it does accept. Presumably, the sender of the request will resend, if
possible, limiting the included bodies to those specified in the Accept.
Minimal telephony SIP implementations might only Accept application/sdp,
certainly.

I'm not sure if this constitutes choking - it may slow session set-up time,
but it shouldn't result in crashes, undefined behavior, etc. In my
experience, even some small user agents (SIP phones) implement this 415
mechanism.

There is also the Content-Disposition header, which allows the sender of a
SIP message to indicate whether or not a given MIME body is necessary for
processing the session... but I'm not sure how widely implemented
Content-Disposition is to date. With Content-Disposition the session will
not be unnecessarily delayed by 415-style negotiation.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Eric Burger [mailto:eburger@snowshore.com]
Sent: Thursday, January 04, 2001 4:58 PM
To: sip@lists.bell-labs.com
Subject: [SIP] SIP App Components


The SIP App Components infrastructure assumes that the SIP UA's understand
multipart MIME body parts.  This is a MAY in bis 02 (Section 8.2).

Is it safe to assume that the current SIP infrastructure won't choke on SIP
INVITES and potentially responses with multipart MIME, instead of
application/sdp, body parts?


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 04:25:50 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08017
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 04:25:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8032B44337; Fri,  5 Jan 2001 03:26:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb14.rediffmail.com (unknown [203.199.83.22])
	by lists.bell-labs.com (Postfix) with SMTP id E561144336
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 03:25:10 -0500 (EST)
Received: (qmail 30665 invoked by uid 510); 5 Jan 2001 09:21:58 -0000
Message-ID: <20010105092158.30664.qmail@mailweb14.rediffmail.com>
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
From: "Deepak  Mohan" <deepakwarrier@rediffmail.com>
Content-ID: <Fri_Jan__5_14_51_57_IST_2001_0@mailweb14.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Subject: [SIP] "Accept-Encoding" in Table 4
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 5 Jan 2001 09:21:58 -0000
Content-Transfer-Encoding: 7bit

Why is it, according to Table 4(draft-ietf-sip-rfc2543bis-02) that "Accept-Encoding" does not have a row entry for responses other than 415, while "Accept" does?

Thanks,
Deepak



_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 07:52:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09512
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 07:52:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2FFF244337; Fri,  5 Jan 2001 06:53:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web10306.mail.yahoo.com (web10306.mail.yahoo.com [216.136.130.84])
	by lists.bell-labs.com (Postfix) with SMTP id D737744336
	for <SIP@lists.bell-labs.com>; Fri,  5 Jan 2001 06:52:31 -0500 (EST)
Message-ID: <20010105125220.94940.qmail@web10306.mail.yahoo.com>
Received: from [203.200.4.11] by web10306.mail.yahoo.com; Fri, 05 Jan 2001 04:52:20 PST
From: james jack <sipjames@yahoo.com>
To: SIP@lists.bell-labs.com, schulzrinne@cs.columbia.edu,
        schooler@cs.caltech.edu
Cc: HenrHenry.Sinnreich@wcom.com, jdrosen@dynamicsoft.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] Consultation on Multicast
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 5 Jan 2001 04:52:20 -0800 (PST)

Dear All:
   I have one question to consult, On page 57 of
RFC2543bis02(PDF format),In section "6.46.1 Requests",

the description on Via, which describes
"A client that sends a request to a multicast address
MUST add the "maddr" parameter to its Via header
field, and SHOULD add the "ttl" parameter. (In that
case, the maddr parameter SHOULD contain the
destination multicast address, although under
exceptional circumstances it MAY contain a unicast
address.)"

  But on page 81, in section "12.3.1 Proxying
Requests", which describes
"A Proxy server MUSTNOT forward a request to a
multicast group which already appears in any of the
Via headers."
   Then I have one doubt, if a client send a request
to a multicast group, if this request is passed
through one proxy, then this proxy will not forward
this request according to the previous description!
   Is that right?
   Could anyone give me suggestion?
   I am looking foreard to getting your reply as soon 
as possible!
    Best regards!
                  yours: james


 
It means the proxy will never forward multicast
request.
 

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 07:55:50 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09559
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 07:55:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E1D464433F; Fri,  5 Jan 2001 06:56:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from wehq.winbond.com.tw (wehq.winbond.com.tw [202.39.229.15])
	by lists.bell-labs.com (Postfix) with ESMTP id 51B8D44336
	for <sip@lists.bell-labs.com>; Thu,  4 Jan 2001 15:45:46 -0500 (EST)
Received: from wehqimc.winbond.com.tw (wehqimc [10.2.6.99])
	by wehq.winbond.com.tw (8.10.0/8.10.0) with ESMTP id f04LjXq23634
	for <sip@lists.bell-labs.com>; Fri, 5 Jan 2001 05:45:33 +0800 (CST)
Received: by wehqimc with Internet Mail Service (5.5.2650.21)
	id <C26J09M0>; Fri, 5 Jan 2001 05:45:28 +0800
Message-ID: <024D43D1894BD111859700A0C989534D016B2CC6@WECAML01>
From: PD20 Jennifer Xu <JYXu@winbond.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] SIP digest authentication
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 5 Jan 2001 05:39:24 +0800

I have a doubt regarding digest authentication processing in between SIP UA
and UA, how can one side UA let remote side UA know their username and
password information? I can not find the clear answer from the SIP spec.
Could some one please advice. Thanks! 



Jennifer Y. Xu

Winbond Electronic Corp. America
408-474-1674
jyxu@winbond.com


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 10:17:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14540
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 10:17:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3B65844337; Fri,  5 Jan 2001 09:18:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id 739B544336
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 09:17:31 -0500 (EST)
Received: (qmail 9580 invoked by uid 500); 5 Jan 2001 15:47:27 -0000
From: David Frascone <dave@frascone.com>
To: Henry Sinnreich <Henry.Sinnreich@wcom.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
        Michael Thomas <mat@cisco.com>, SIP List <sip@lists.bell-labs.com>,
        C.T.A.M.deLaat@phys.uu.nl, jrv@interlinknetworks.com
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
Message-ID: <20010105094726.A9558@newman.frascone.com>
Mail-Followup-To: Henry Sinnreich <Henry.Sinnreich@wcom.com>,
	Pat Calhoun <Pat.Calhoun@eng.sun.com>,
	"Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
	Michael Thomas <mat@cisco.com>, SIP List <sip@lists.bell-labs.com>,
	C.T.A.M.deLaat@phys.uu.nl, jrv@interlinknetworks.com
References: <Roam.SIMC.2.0.6.978476425.10317.pcalhoun@nasnfs> <NEBBLDFFKGAJDPBENMDNGEGIDGAA.Henry.Sinnreich@wcom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <NEBBLDFFKGAJDPBENMDNGEGIDGAA.Henry.Sinnreich@wcom.com>; from Henry.Sinnreich@wcom.com on Thu, Jan 04, 2001 at 12:03:48PM -0600
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 5 Jan 2001 09:47:26 -0600

> As for the question why XML/HTTP:
> 
> ISP services development and operations costs are minimized by using the
> smallest number of protocols and data formats.
> HTTP clearly makes it to the top of the short list for transport.
> XML has countless tools for dummies (like me) and can be displayed with the
> browser and is thus ideal for testing and prototyping in this fast changing
> environment. It is has also a large field of applicability. DIAMETER with
> its AVP data formats does not have these advantages - may have its place as
> mentioned for network access, but is not in the center of the AAA universe
> IMHO. Pushing DIAMETER to be the focus of AAA is not convincing.
> 

I'm not sure I follow your reasoning.  I agree that XML is an exelent way
to model data.  But, I have to disagree about it being a good transport.  In
my opinion, AVPs were chosen because the are extensible, and, SMALL.  And,
since they are binary, they do not have to be parsed, but can be manipulated
by pointing a structure at them.

Any of the data transported in AVPs could be *viewed* with an XML viewer after
a small conversion.  Accounting data could also be sent as XML.  Any XML
payload could be sent inside of AVPs.

But, I *still* don't understand why you would want the TRANSPORT to be 
XML.  We are still talking about the TRANSPORT, right?  What is the reasoning
for having XML on the wire? 

<sarcastic hat> I mean, if we are going to use it as the transport, why stop
there?  Why not XML over IP?  XML over ethernet? </sarcastic hat>

Please, If I'm missing something, let me know.  But I am haveing serious
trouble following your need for being able to sniff XML packets on the wire.


Dave Frascone

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 10:44:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15296
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 10:44:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C455844337; Fri,  5 Jan 2001 09:45:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 7BBEA44336
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 09:44:19 -0500 (EST)
Received: from bounty.cisco.com (bounty.cisco.com [161.44.3.204])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA15041;
	Fri, 5 Jan 2001 07:44:05 -0800 (PST)
From: David Daiker <ddaiker@cisco.com>
To: PD20 Jennifer Xu <JYXu@winbond.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP digest authentication
In-Reply-To: <024D43D1894BD111859700A0C989534D016B2CC6@WECAML01>
Message-ID: <Pine.GSO.4.21.0101051038180.29768-100000@bounty.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 5 Jan 2001 10:43:26 -0500 (EST)


the short answer is that username and response (not password)
are provided as parameters to the authorization header,
both parties have access to the user's password

the long (and best) answer is to read rfc.2617 - http digest access
authentication

hth,
david

On Fri, 5 Jan 2001, PD20 Jennifer Xu wrote:

> I have a doubt regarding digest authentication processing in between SIP UA
> and UA, how can one side UA let remote side UA know their username and
> password information? I can not find the clear answer from the SIP spec.
> Could some one please advice. Thanks! 
> 
> 
> 
> Jennifer Y. Xu
> 
> Winbond Electronic Corp. America
> 408-474-1674
> jyxu@winbond.com
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 10:52:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15385
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 10:52:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 83F8A44349; Fri,  5 Jan 2001 09:53:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60])
	by lists.bell-labs.com (Postfix) with ESMTP id C3A3F44336
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 09:52:31 -0500 (EST)
Received: from cvis01.gpt.co.uk (unverified) by cvis28.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc363f43c50ec109b2d@cvis28.marconicomms.com> for <sip@lists.bell-labs.com>;
 Fri, 5 Jan 2001 15:51:34 +0000
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-30) id PAA15706; Fri, 5 Jan 2001 15:51:33 GMT
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 802569CB.005711FB ; Fri, 5 Jan 2001 15:51:02 +0000
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Keith Robinson" <Keith.Robinson@marconi.com>
To: sip@lists.bell-labs.com
Message-ID: <802569CB.0057108C.00@marconicomms.com>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] Overlap Sending
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 5 Jan 2001 15:50:45 +0000



I have the following query regarding overlap sending as defined in
rfc2543bis-02:

Section 4.2.1 states the following:

"...the UAS compares the Request-URI with Request-URI of the previous INVITE
request
for the same Call-Id. If the Request-URI  contains additional digits in the
'user' part, the UAS
treats the INVITE as adding additional digits to the original dialed string."

This appears to imply that the subsequent INVITE contains the original dialled
string plus the
additional digits; if this is the case, then there is no need for the UAS to
remember the
previous string, and therefore no need to keep any state regarding the previous
attempt.
The subsequent INVITE can really be a new INVITE., i.e. a new Call-Id.

If, on the other hand, the sending UA only sends additional digits, then the
original digits
will have to be remembered by the UAS, and the INVITE matched up with this state
so
this INVITE must be on the same Call-Id.

This latter case is similar to the way existing telephony protocols transmit
addtional digits
when doing overlap sending.

So, upon receiving a response of 484 Address Incomplete, does the sending UA
send
original digits plus aditional digits on a new Call-Id or additional digits only
on the same
Call-Id with an incremented Cseq.

Regards,

K. Robinson.




_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 12:00:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16684
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 12:00:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1006744337; Fri,  5 Jan 2001 11:01:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail-dns1-nj.dialogic.com (mail-dns1-nj.dialogic.com [146.152.228.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 796F144336
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 11:00:23 -0500 (EST)
Received: from mail4.dialogic.com ([146.152.6.40])
	by mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: dialogic.m4,v 1.3 2000/05/05 13:56:23 dmccart Exp $) with ESMTP id RAA06328;
	Fri, 5 Jan 2001 17:07:00 GMT
Received: from jamarkdesk (jamark-desk.sb.dialogic.com [146.152.131.156])
	by mail4.dialogic.com (8.9.3+Sun/8.9.3) with SMTP id MAA01645;
	Fri, 5 Jan 2001 12:00:08 -0500 (EST)
From: "Jeff Mark" <Jeff.Mark@dialogic.com>
To: "'Vijeth  D'" <vijethd@rediffmail.com>, <sip@lists.bell-labs.com>
Subject: RE: [SIP] Also field
Message-ID: <A034983ED521D4119F5B00105A0C3807026A29@exchange1nj.dialogic.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <20010105061447.14613.qmail@mailweb7.rediffmail.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 5 Jan 2001 09:00:04 -0800
Content-Transfer-Encoding: 8bit

This is what I see as the syntax from section 6.11 of the Nov 24
draft-ietf-sip-rfc2543bis-02.txt:

	Also  =  "Also" ":" 1# (( name-addr | addr-spec )

And, I thought the BYE/Also mechanism for Transfer was deprecated in
favor of the REFER method so I'm a bit confused on why it has appeared
in the bis draft.  Can anyone refresh my memory?

Thanks,

-Jeff


From: Vijeth D [mailto:vijethd@rediffmail.com]
>
> Hi,
>   The syntax of the also header field is not very clear.
> Also = ”Also” ”:” 1# (( name-addr — addr-spec )
>
> First of all a closing parantheses is missing and secondly
> what is the meaning of a '-' between name-addr and addr-spec?
>
> Thanks,
>


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 12:16:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17104
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 12:16:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4A8624434C; Fri,  5 Jan 2001 11:17:02 -0500 (EST)
Delivered-To: sip@share.research.bell-labs.com
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by lists.bell-labs.com (Postfix) with SMTP id 36AE644337
	for <sip@share.research.bell-labs.com>; Fri,  5 Jan 2001 11:16:16 -0500 (EST)
Received: from lists.bell-labs.com ([135.104.27.211]) by dirty; Fri Jan  5 12:14:57 EST 2001
Received: by lists.bell-labs.com (Postfix)
	id 3039B44380; Fri,  5 Jan 2001 12:01:48 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by lists.bell-labs.com (Postfix) with ESMTP id 0DDA14437D
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 12:01:48 -0500 (EST)
Received: from cs.columbia.edu (ume [135.180.240.103])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA28587;
	Fri, 5 Jan 2001 12:01:47 -0500 (EST)
Message-ID: <3A55FDE5.E891C084@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Deepak Mohan <deepakwarrier@rediffmail.com>
Cc: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
Subject: Re: [SIP] "Accept-Encoding" in Table 4
References: <20010105092158.30664.qmail@mailweb14.rediffmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 05 Jan 2001 12:01:25 -0500
Content-Transfer-Encoding: 7bit



Deepak Mohan wrote:
> 
> Why is it, according to Table 4(draft-ietf-sip-rfc2543bis-02) that "Accept-Encoding" does not have a row entry for responses other than 415, while "Accept" does?
> 

Accept is also allowed for 200 responses. I suppose that's true for the
others, too. I don't think there are any other responses where Accept*
makes much sense.

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 12:17:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17144
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 12:17:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DD4DF44352; Fri,  5 Jan 2001 11:18:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from shell.dhp.com (shell.dhp.com [199.245.105.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 2025D44337
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 11:17:32 -0500 (EST)
Received: by shell.dhp.com (Postfix, from userid 668)
	id 65FB01E40E; Fri,  5 Jan 2001 12:17:19 -0500 (EST)
From: Billy Biggs <vektor@div8.net>
To: Jeff Mark <Jeff.Mark@dialogic.com>
Cc: "'Vijeth D'" <vijethd@rediffmail.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Also field
In-Reply-To: <A034983ED521D4119F5B00105A0C3807026A29@exchange1nj.dialogic.com>
Message-ID: <Pine.LNX.4.21.0101051216120.4024-100000@shell.dhp.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 5 Jan 2001 12:17:19 -0500 (EST)

On Fri, 5 Jan 2001, Jeff Mark wrote:

> And, I thought the BYE/Also mechanism for Transfer was deprecated in
> favor of the REFER method so I'm a bit confused on why it has appeared
> in the bis draft.  Can anyone refresh my memory?

  Since everyone has implemented it, the suggestion was to add it to the
bis.  However, many people have objected, and it will likely be removed.

--
Billy Biggs                         vektor@div8.net
http://www.div8.net/billy       wbiggs@uwaterloo.ca


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 12:31:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17467
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 12:31:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3731144349; Fri,  5 Jan 2001 11:32:02 -0500 (EST)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id A5FAC44336
	for <sip@share.research.bell-labs.com>; Fri,  5 Jan 2001 11:31:27 -0500 (EST)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jan  5 12:28:15 EST 2001
Received: by lists.bell-labs.com (Postfix)
	id 3E8C544380; Fri,  5 Jan 2001 12:16:20 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by lists.bell-labs.com (Postfix) with ESMTP id 1B4E64437D
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 12:16:20 -0500 (EST)
Received: from cs.columbia.edu (ume [135.180.240.103])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA29668;
	Fri, 5 Jan 2001 12:16:19 -0500 (EST)
Message-ID: <3A56014D.8E66F663@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Mozilla 4.61 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jeff Mark <Jeff.Mark@dialogic.com>
Cc: "'Vijeth D'" <vijethd@rediffmail.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] Also field
References: <A034983ED521D4119F5B00105A0C3807026A29@exchange1nj.dialogic.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 05 Jan 2001 12:15:57 -0500
Content-Transfer-Encoding: 7bit



Jeff Mark wrote:
> 
> This is what I see as the syntax from section 6.11 of the Nov 24
> draft-ietf-sip-rfc2543bis-02.txt:
> 
>         Also  =  "Also" ":" 1# (( name-addr | addr-spec )
> 
> And, I thought the BYE/Also mechanism for Transfer was deprecated in
> favor of the REFER method so I'm a bit confused on why it has appeared
> in the bis draft.  Can anyone refresh my memory?
> 

It was requested as reflecting current implementation practice. The idea
of putting things into the draft (it being called a draft...), is to get
people to speak up and complain. Otherwise, nothing ever gets settled.

I suppose there are two solutions:

- Remove Also as duplicating REFER (whatever it's final shape turns out
to be). This follows the "one-task, one-approach" rule. 

- If REFER turns into a monster protocol that requires SUBSCRIBE,
NOTIFY, XML parsing and who knows what else for a simple blind transfer,
then I suspect that many implementations will use it regardless of what
the bis spec says or doesn't say.

Thus, I think it's time to arrive at some closure on the REFER issue. In
my personal opinion, NOTIFY (with the status responses as a message/sip
body rather than some new message format) and implied subscription seems
to be a reasonable compromise between complexity and generality,
possibly with some hint in the request as to whether notifications are
desired or not.

To muddy the water a bit more with an unrelated topic, I wonder if some
of the ugliness of encoding methods and headers in the Refer-To URL
could be avoided by also attaching the message to be generated as a
message/sip body.

Henning

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 13:03:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18286
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 13:03:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7F44344337; Fri,  5 Jan 2001 12:04:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by lists.bell-labs.com (Postfix) with ESMTP id 5CB8F44336
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 12:03:52 -0500 (EST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Fri, 5 Jan 2001 09:08:20 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 05 Jan 2001 09:09:02 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532);
	 Fri, 5 Jan 2001 09:08:55 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0
content-class: urn:content-classes:message
Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Message-ID: <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9E7@speak.dogfood>
Thread-Topic: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
Thread-Index: AcB3KtgFkK3zrLynStSOk3XxUU/9oQACXC6A
From: "Christian Huitema" <huitema@exchange.microsoft.com>
To: "David Frascone" <dave@frascone.com>,
        "Henry Sinnreich" <Henry.Sinnreich@wcom.com>
Cc: "Pat Calhoun" <Pat.Calhoun@eng.sun.com>,
        "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
        "Michael Thomas" <mat@cisco.com>, "SIP List" <sip@lists.bell-labs.com>,
        <C.T.A.M.deLaat@phys.uu.nl>, <jrv@interlinknetworks.com>
X-OriginalArrivalTime: 05 Jan 2001 17:08:55.0399 (UTC) FILETIME=[2F6F0F70:01C0773A]
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 5 Jan 2001 08:34:17 -0800
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA18286

I don't really see why this discussion is going on on the SIP list.
There seem to be a campaign going on to promote Diameter as a solution
to every yet unstated problem in networking; yet Diameter is hardly more
than an unsanctioned draft proposal whose questionable engineering cause
the draft to undergo 17 revisions without yet being convincing. The AAA
group should probably focus on solving the problem they are chartered to
solve, i.e. a successor to Radius for network access, before trying to
expand the scope of application. We should revisit the issue in the SIP
group after the work of the AAA group has reached the draft standard
stage.

As for the assertion that AVP is generically better than text encoding,
this look like a rehash of the binary versus text debate that took place
in Megaco from 1998 to 2000. For the record, the one point of comparison
I have is that of the text based SGCP versus the Diameter based ICMP;
both where solving the same problem; SGCP messages were actually
shorter. The reason for that wasthe particularly bloated brand of AVP
used in Diameter, which is probably one of the worse designs I ever saw.
Heck, compared to the Diameter syntax, ASN.1/BER looks good!

-- Christian Huitema

> -----Original Message-----
> From: David Frascone [mailto:dave@frascone.com]
> Sent: Friday, January 05, 2001 7:47 AM
> To: Henry Sinnreich
> Cc: Pat Calhoun; Henning G. Schulzrinne; Michael Thomas; SIP List;
> C.T.A.M.deLaat@phys.uu.nl; jrv@interlinknetworks.com
> Subject: Re: [aboba@internaut.com: Re: [SIP] 
> draft-calhoun-sip-aaa-req]
> 
> 
> > As for the question why XML/HTTP:
> > 
> > ISP services development and operations costs are minimized 
> by using the
> > smallest number of protocols and data formats.
> > HTTP clearly makes it to the top of the short list for transport.
> > XML has countless tools for dummies (like me) and can be 
> displayed with the
> > browser and is thus ideal for testing and prototyping in 
> this fast changing
> > environment. It is has also a large field of applicability. 
> DIAMETER with
> > its AVP data formats does not have these advantages - may 
> have its place as
> > mentioned for network access, but is not in the center of 
> the AAA universe
> > IMHO. Pushing DIAMETER to be the focus of AAA is not convincing.
> > 
> 
> I'm not sure I follow your reasoning.  I agree that XML is an 
> exelent way
> to model data.  But, I have to disagree about it being a good 
> transport.  In
> my opinion, AVPs were chosen because the are extensible, and, 
> SMALL.  And,
> since they are binary, they do not have to be parsed, but can 
> be manipulated
> by pointing a structure at them.
> 
> Any of the data transported in AVPs could be *viewed* with an 
> XML viewer after
> a small conversion.  Accounting data could also be sent as 
> XML.  Any XML
> payload could be sent inside of AVPs.
> 
> But, I *still* don't understand why you would want the 
> TRANSPORT to be 
> XML.  We are still talking about the TRANSPORT, right?  What 
> is the reasoning
> for having XML on the wire? 
> 
> <sarcastic hat> I mean, if we are going to use it as the 
> transport, why stop
> there?  Why not XML over IP?  XML over ethernet? </sarcastic hat>
> 
> Please, If I'm missing something, let me know.  But I am 
> haveing serious
> trouble following your need for being able to sniff XML 
> packets on the wire.
> 
> 
> Dave Frascone
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 13:05:31 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18350
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 13:05:31 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 58E5D44351; Fri,  5 Jan 2001 12:05:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16])
	by lists.bell-labs.com (Postfix) with ESMTP id A929844352
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 12:04:11 -0500 (EST)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260)
 id <0G6P00901BILHX@firewall.mcit.com> for sip@lists.bell-labs.com; Fri,
 5 Jan 2001 18:03:57 +0000 (GMT)
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0G6P007JSBILOU@firewall.mcit.com>; Fri,
 05 Jan 2001 18:03:57 +0000 (GMT)
Received: from CONVERSION-DAEMON by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 id <0G6P00001BIL1P@pmismtp02.wcomnet.com>; Fri,
 05 Jan 2001 18:03:57 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with SMTP id <0G6P00001BIG0M@pmismtp02.wcomnet.com>;
 Fri, 05 Jan 2001 18:03:57 +0000 (GMT)
Received: from hsinnreich ([166.35.226.44])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with SMTP id <0G6P00M2QBI3VZ@pmismtp02.wcomnet.com>; Fri,
 05 Jan 2001 18:03:41 +0000 (GMT)
From: Henry Sinnreich <Henry.Sinnreich@wcom.com>
Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
In-reply-to: <5.0.2.1.2.20010104145214.02157ec0@pop3.ipverse.com>
To: Matt Holdrege <matt@ipverse.com>,
        "Gross, Gerhard" <gerhard.gross@intel.com>,
        SIP List <sip@lists.bell-labs.com>
Message-id: <NEBBLDFFKGAJDPBENMDNKEHPDGAA.Henry.Sinnreich@wcom.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 05 Jan 2001 12:03:55 -0600
Content-Transfer-Encoding: 7bit

>we're worried about programmers who are inexperienced

top talent is hard to get and adds to cost...

> Let them go 
> to school and learn binary 

Am not sure this is a good idea. Prefer non-binary coded.

Henry

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Matt Holdrege
> Sent: Thursday, January 04, 2001 4:54 PM
> To: Gross, Gerhard; SIP List
> Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
> 
> 
> At 12:43 PM 1/4/2001, Gross, Gerhard wrote:
> >Furthermore, concerning
> >
> > > As for the question why XML/HTTP:
> >
> >(paraphrasing one of my colleagues):
> >
> >A major drawback of AVP is that it uses
> >a binary (non-textual) representation
> >requiring programmers and the appropriate
> >programming tools to use and understand it.
> 
> Just a nit of mine, but I really hate it when we have to 
> sacrifice quality 
> because we're worried about programmers who are inexperienced. 
> Let them go 
> to school and learn binary and let the end-users have what they 
> need. There 
> are plenty of coders who can handle binary just fine.
> 
> I'm not against XML, rather I'm in favor of it. But let's not use 
> the above 
> as an excuse.
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 13:10:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18505
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 13:10:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B91684435A; Fri,  5 Jan 2001 12:11:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 2121C44348
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 12:10:24 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f05IA0F02000;
	Fri, 5 Jan 2001 12:10:00 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: Henning Schulzrinne <hgs@cs.columbia.edu>
Cc: Jeff Mark <Jeff.Mark@dialogic.com>, "'Vijeth D'" <vijethd@rediffmail.com>,
        sip@lists.bell-labs.com
Subject: Re: [SIP] Also field (Refer-status)
Message-ID: <20010105121000.A12175@fdd.com>
References: <A034983ED521D4119F5B00105A0C3807026A29@exchange1nj.dialogic.com> <3A56014D.8E66F663@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A56014D.8E66F663@cs.columbia.edu>; from hgs@cs.columbia.edu on Fri, Jan 05, 2001 at 12:15:57PM -0500
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 5 Jan 2001 12:10:00 -0600

On Fri, Jan 05, 2001 at 12:15:57PM -0500, Henning Schulzrinne wrote:
> 
> - Remove Also as duplicating REFER (whatever it's final shape turns out
> to be). This follows the "one-task, one-approach" rule. 
> 
> - If REFER turns into a monster protocol that requires SUBSCRIBE,
> NOTIFY, XML parsing and who knows what else for a simple blind transfer,
> then I suspect that many implementations will use it regardless of what
> the bis spec says or doesn't say.
> 
> Thus, I think it's time to arrive at some closure on the REFER issue. In
> my personal opinion, NOTIFY (with the status responses as a message/sip
> body rather than some new message format) and implied subscription seems
> to be a reasonable compromise between complexity and generality,
> possibly with some hint in the request as to whether notifications are
> desired or not.

A re-INVITE with a Refer-Status: header is easier to code 
and parse.  The (single-part) body can then contain SDP.
It will all fit inside of a non-fragmented datagram.
More importantly, the response to the re-INVITE can be
a 180 ringing as need be.

--
Rick
rick_dean@3com.com

> 
> To muddy the water a bit more with an unrelated topic, I wonder if some
> of the ugliness of encoding methods and headers in the Refer-To URL
> could be avoided by also attaching the message to be generated as a
> message/sip body.
> 
> Henning
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 13:44:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19350
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 13:44:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8596E44337; Fri,  5 Jan 2001 12:45:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id 94F3144336
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 12:44:34 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28790;
	Fri, 5 Jan 2001 10:44:13 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA07887;
	Fri, 5 Jan 2001 10:44:12 -0800 (PST)
Received: from mordor (mordor [129.146.120.122])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA09397;
	Fri, 5 Jan 2001 10:44:10 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Reply-To: Pat Calhoun <Pat.Calhoun@eng.sun.com>
Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
To: Christian Huitema <huitema@exchange.microsoft.com>
Cc: David Frascone <dave@frascone.com>,
        Henry Sinnreich <Henry.Sinnreich@wcom.com>,
        Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
        Michael Thomas <mat@cisco.com>, SIP List <sip@lists.bell-labs.com>,
        C.T.A.M.deLaat@phys.uu.nl, jrv@interlinknetworks.com
In-Reply-To: "Your message with ID" <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9E7@speak.dogfood>
Message-ID: <Roam.SIMC.2.0.6.978720038.5484.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 5 Jan 2001 10:40:38 -0800 (PST)

> I don't really see why this discussion is going on on the SIP list.

So why do you bother with the following then? If you want to keep these
discussions off the list, then leaving it be would have been the best
approach. 

Of course, after being (nearly) personally insulted, it is rather hard for me
to ignore your comments.

> There seem to be a campaign going on to promote Diameter as a solution
There is no campaign that I am aware of.

> to every yet unstated problem in networking;

Every yet unstated problem in networking? Well, let me see, we have wide
support to solve Network Access (PPP, mostly used for wireline and some
wireless & Mobile IP for wireless) and we have started to put together some
requirements for SIP given that some 3G bodies want to re-use their AAA
infrastructure for it.

Far from all of networking. Wouldn't you agree?

> yet Diameter is hardly more
> than an unsanctioned draft proposal 

Perhaps you'd be interested in reading the AAA WG charter, which is working on
the DIAMETER protocol (yes, the WG did select the DIAMETER protocol as the
base from which to start). The charter can be found at
http://www.ietf.org/html.charters/aaa-charter.html

> whose questionable engineering cause
> the draft to undergo 17 revisions without yet being convincing.

ok, fair enough. 17 revisions since 1995, which means lots of input from the
community, even before it was an IETF document.

Of course, please keep in mind that many of these revisions were based on
RADIUS operational experience, changes in how RADIUS in used in the net over
the years (hence the roamops WG), and further simplifications of the protocol.
However, if we are to judge a protocol based on the number of revisions it
took before it went to last call, then I believe that many I-Ds would fall
under the category of "questionable engineering". 

As an aside, how many revisions does it take before a protocol becomes
questionable engineering?

> The AAA
> group should probably focus on solving the problem they are chartered to
> solve, i.e. a successor to Radius for network access, before trying to
> expand the scope of application. We should revisit the issue in the SIP
> group after the work of the AAA group has reached the draft standard
> stage.

The AAA WG is continuing with their effort, as shown in the charter and
archives. We already have text to apply to the DIAMETER specs that have been
the result of lots of work in design teams, and is under working group review.

oh, and the SIP/AAA requirements I-D has nothing to do with the AAA WG. This
is an independend effort to gather *requirements*, requirements that should
not even affect the SIP protocol. However, we decided that the best place to
do this is in SIP, where people understand how it works, and how it is
deployed. 

so I really don't understand the protocol attack going on. Why not attack the
requirements?

Once we can agree on a set of requirements, then we can choose a protocol. We
provided the model that the 3G community is assuming in our draft for
reference, but I have yet to hear any comments on the actual requirements.

[more protocol bashing deleted]

PatC


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 14:27:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20444
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 14:27:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BCF5644337; Fri,  5 Jan 2001 13:28:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by lists.bell-labs.com (Postfix) with ESMTP id EBFD244336
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 13:27:09 -0500 (EST)
Received: from dingdong.cisco.com (dingdong.cisco.com [161.44.3.16])
	by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA26692;
	Fri, 5 Jan 2001 14:26:48 -0500 (EST)
Received: from slevy-pc (dhcp-64-102-97-120.cisco.com [64.102.97.120])
	by dingdong.cisco.com (Mirapoint)
	with SMTP id AAW26389;
	Fri, 5 Jan 2001 14:26:58 -0500 (EST)
Message-Id: <4.1.20010105130115.00dc8640@dingdong.cisco.com>
X-Sender: stlevy@dingdong.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
To: "Keith Robinson" <Keith.Robinson@marconi.com>, sip@lists.bell-labs.com
From: Steve Levy <stlevy@cisco.com>
Subject: Re: [SIP] Overlap Sending
In-Reply-To: <802569CB.0057108C.00@marconicomms.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 05 Jan 2001 14:32:00 -0800

Hi Keith, 

I was wondering if in considering overlap sending issues and SIP if you were considering the case of overlap sending across multiple networks with variable length digits.

In this case, in order to avoid post dial delay, the digits need to be passed through the networks to the final destiantion network prior to end of dial (since the destination network is the only network that knows how many digits are required). So in effect there may be additional digits sent after an INVITE has been received and sent downstream to the callee.  

Thanks,
Steve 


At 03:50 PM 1/5/01 +0000, Keith Robinson wrote:
>
>
>I have the following query regarding overlap sending as defined in
>rfc2543bis-02:
>
>Section 4.2.1 states the following:
>
>"...the UAS compares the Request-URI with Request-URI of the previous INVITE
>request
>for the same Call-Id. If the Request-URI  contains additional digits in the
>'user' part, the UAS
>treats the INVITE as adding additional digits to the original dialed string."
>
>This appears to imply that the subsequent INVITE contains the original dialled
>string plus the
>additional digits; if this is the case, then there is no need for the UAS to
>remember the
>previous string, and therefore no need to keep any state regarding the previous
>attempt.
>The subsequent INVITE can really be a new INVITE., i.e. a new Call-Id.
>
>If, on the other hand, the sending UA only sends additional digits, then the
>original digits
>will have to be remembered by the UAS, and the INVITE matched up with this 
>state
>so
>this INVITE must be on the same Call-Id.
>
>This latter case is similar to the way existing telephony protocols transmit
>addtional digits
>when doing overlap sending.
>
>So, upon receiving a response of 484 Address Incomplete, does the sending UA
>send
>original digits plus aditional digits on a new Call-Id or additional digits 
>only
>on the same
>Call-Id with an incremented Cseq.
>
>Regards,
>
>K. Robinson.
>
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 14:56:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21139
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 14:56:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 772B544337; Fri,  5 Jan 2001 13:57:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by lists.bell-labs.com (Postfix) with ESMTP id B846B44336
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 13:56:17 -0500 (EST)
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Fri, 5 Jan 2001 14:55:40 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBQ2JL>; Fri, 5 Jan 2001 14:55:41 -0500
Message-ID: <28560036253BD41191A10000F8BCBD1103473970@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: Sean Olson <sean.olson@ericsson.com>, Billy Biggs <Billy_Biggs@3com.com>
Cc: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
        Rohan Mahy <rohan@cisco.com>, Robert Sparks <rsparks@dynamicsoft.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Solving the REFER retransmit issue
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C07751.7A0295E0"
X-Orig: <taylor@americasm01.nt.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 5 Jan 2001 14:55:38 -0500

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_01C07751.7A0295E0
Content-Type: text/plain;
	charset="iso-8859-1"

I've been reviewing this thread in response to the latest messages about the
Also: header, and fully support the operation of REFER in the way Sean
describes it.  In particular, I need a way for an operator to tell a
conference server to add a party to a conference without including the
operator in that conference.

Just to remind people, where we are talking about A sending a REFER to B to
tell B to send an INVITE to C, there is still the problem of how C knows
whether the incoming call
  - replaces an existing call
  - is another party to an existing call
  - is an unrelated call.

The only durable answer I recall for this one is Jonathan's advice: let the
user at C decide.  

> -----Original Message-----
> From: Sean Olson [mailto:sean.olson@ericsson.com]
> Sent: Friday, December 22, 2000 11:56 AM
> To: Billy Biggs
> Cc: Henning G. Schulzrinne; Rohan Mahy; Robert Sparks; Jonathan
> Rosenberg; sip@lists.bell-labs.com
> Subject: Re: [SIP] Solving the REFER retransmit issue
> 
> 
> I have to confess that I prefer the notion of a REFER that is outside
> of any active (INVITE) session. Separating the REFER and INVITE 
> seems the most natural to me. In this case, there would be no 
> re-INVITE
> to carry this header (if I understand your suggestion correctly)
> 
> What I would prefer to see is a NOTIFY sent for responses with the
> REFER acting as an implicit SUBSCRIBE and a new Refer-Notify: header
> in the REFER request which would indicate the desire to receive
> such notifications. 
> 
> Refer-Notify: (name-addr | addr-spec)
> 
> If the Refer-Notify: header is present in the request, 
> it indicates the desire to receive NOTIFYs for the responses.
> If the Refer-Notify: header is present in the response,
> it indicates that the receiver is willing to send NOTIFYs (of
> course only applicable to a 2xx response to the REFER)
> 
> I think this will allow for the most common cases without
> incurring any great overhead or restricting the possibilities.
> 
> /sean
> 
> 
> Billy Biggs wrote:
> > 
> > Sean Olson (sean.olson@ericsson.com):
> > 
> > > > > It is not clear that this is workable if REFER is treated as a
> > > > > means of executing a generic request somewhere else, 
> not limited
> > > > > to INVITE.
> > > >
> > > >   And obfuscate this request in a URI?
> > > >
> > > >   Is this a specific feature or just for protocol cleanness?
> > > > Executing a generic request may have dangerous security
> > > > implications.
> > >
> > > This is no more insecure than a REFER with INVITE as the 
> method.  I
> > > actually like the idea of being able to REFER a SUBSCRIBE 
> or even a
> > > REGISTER. I realize the implications of this but I don't 
> think it's
> > > much different than receiving a REFER with an INVITE for which you
> > > might be billed.
> > 
> >   Do you need to know the response to the 
> SUBSCRIBE/REGISTER?  If so,
> > can you live with it as a header in a re-INVITE?  It will 
> save alot of
> > trouble, and optimizes the most common case.
> > 
> > --
> > Billy Biggs, 3Com               Email: Billy_Biggs@3com.com
> > http://www.div8.net/billy/      Phone: Billy_Biggs@sip.3com.com
> > 
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

------_=_NextPart_001_01C07751.7A0295E0
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [SIP] Solving the REFER retransmit issue</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I've been reviewing this thread in response to the =
latest messages about the Also: header, and fully support the operation =
of REFER in the way Sean describes it.&nbsp; In particular, I need a =
way for an operator to tell a conference server to add a party to a =
conference without including the operator in that =
conference.</FONT></P>

<P><FONT SIZE=3D2>Just to remind people, where we are talking about A =
sending a REFER to B to tell B to send an INVITE to C, there is still =
the problem of how C knows whether the incoming call</FONT></P>

<P><FONT SIZE=3D2>&nbsp; - replaces an existing call</FONT>
<BR><FONT SIZE=3D2>&nbsp; - is another party to an existing call</FONT>
<BR><FONT SIZE=3D2>&nbsp; - is an unrelated call.</FONT>
</P>

<P><FONT SIZE=3D2>The only durable answer I recall for this one is =
Jonathan's advice: let the user at C decide.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Sean Olson [<A =
HREF=3D"mailto:sean.olson@ericsson.com">mailto:sean.olson@ericsson.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, December 22, 2000 11:56 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Billy Biggs</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Henning G. Schulzrinne; Rohan Mahy; Robert =
Sparks; Jonathan</FONT>
<BR><FONT SIZE=3D2>&gt; Rosenberg; sip@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [SIP] Solving the REFER retransmit =
issue</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I have to confess that I prefer the notion of a =
REFER that is outside</FONT>
<BR><FONT SIZE=3D2>&gt; of any active (INVITE) session. Separating the =
REFER and INVITE </FONT>
<BR><FONT SIZE=3D2>&gt; seems the most natural to me. In this case, =
there would be no </FONT>
<BR><FONT SIZE=3D2>&gt; re-INVITE</FONT>
<BR><FONT SIZE=3D2>&gt; to carry this header (if I understand your =
suggestion correctly)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; What I would prefer to see is a NOTIFY sent for =
responses with the</FONT>
<BR><FONT SIZE=3D2>&gt; REFER acting as an implicit SUBSCRIBE and a new =
Refer-Notify: header</FONT>
<BR><FONT SIZE=3D2>&gt; in the REFER request which would indicate the =
desire to receive</FONT>
<BR><FONT SIZE=3D2>&gt; such notifications. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Refer-Notify: (name-addr | addr-spec)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If the Refer-Notify: header is present in the =
request, </FONT>
<BR><FONT SIZE=3D2>&gt; it indicates the desire to receive NOTIFYs for =
the responses.</FONT>
<BR><FONT SIZE=3D2>&gt; If the Refer-Notify: header is present in the =
response,</FONT>
<BR><FONT SIZE=3D2>&gt; it indicates that the receiver is willing to =
send NOTIFYs (of</FONT>
<BR><FONT SIZE=3D2>&gt; course only applicable to a 2xx response to the =
REFER)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think this will allow for the most common =
cases without</FONT>
<BR><FONT SIZE=3D2>&gt; incurring any great overhead or restricting the =
possibilities.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; /sean</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Billy Biggs wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sean Olson =
(sean.olson@ericsson.com):</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; It is not clear that this =
is workable if REFER is treated as a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; means of executing a =
generic request somewhere else, </FONT>
<BR><FONT SIZE=3D2>&gt; not limited</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &gt; to INVITE.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&nbsp;&nbsp; And obfuscate this =
request in a URI?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&nbsp;&nbsp; Is this a specific =
feature or just for protocol cleanness?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Executing a generic request may =
have dangerous security</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; implications.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; This is no more insecure than a REFER =
with INVITE as the </FONT>
<BR><FONT SIZE=3D2>&gt; method.&nbsp; I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; actually like the idea of being able =
to REFER a SUBSCRIBE </FONT>
<BR><FONT SIZE=3D2>&gt; or even a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; REGISTER. I realize the implications =
of this but I don't </FONT>
<BR><FONT SIZE=3D2>&gt; think it's</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; much different than receiving a REFER =
with an INVITE for which you</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; might be billed.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; Do you need to know the =
response to the </FONT>
<BR><FONT SIZE=3D2>&gt; SUBSCRIBE/REGISTER?&nbsp; If so,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; can you live with it as a header in a =
re-INVITE?&nbsp; It will </FONT>
<BR><FONT SIZE=3D2>&gt; save alot of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; trouble, and optimizes the most common =
case.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Billy Biggs, =
3Com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp; Email: Billy_Biggs@3com.com</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A HREF=3D"http://www.div8.net/billy/" =
TARGET=3D"_blank">http://www.div8.net/billy/</A>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; Phone: Billy_Biggs@sip.3com.com</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; SIP mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; SIP@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/sip" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></F=
ONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; SIP mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; SIP@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/sip" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></F=
ONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07751.7A0295E0--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 16:57:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23950
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 16:57:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 04AFB44337; Fri,  5 Jan 2001 15:58:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 6C97844336
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 15:57:46 -0500 (EST)
Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f05LvSK00055;
	Fri, 5 Jan 2001 15:57:28 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f05LvSs05434;
	Fri, 5 Jan 2001 15:57:28 -0600 (CST)
Received: from ericsson.com (pc050184.exu.ericsson.se [138.85.50.184]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA03805; Fri, 5 Jan 2001 15:57:27 -0600 (CST)
Message-ID: <3A564347.7080509@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
Cc: Jeff Mark <Jeff.Mark@dialogic.com>, "'Vijeth D'" <vijethd@rediffmail.com>,
        sip@lists.bell-labs.com
Subject: Re: [SIP] Also field
References: <A034983ED521D4119F5B00105A0C3807026A29@exchange1nj.dialogic.com> <3A56014D.8E66F663@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 05 Jan 2001 15:57:27 -0600
Content-Transfer-Encoding: 7bit



Henning Schulzrinne wrote:

> 
> To muddy the water a bit more with an unrelated topic, I wonder if some
> of the ugliness of encoding methods and headers in the Refer-To URL
> could be avoided by also attaching the message to be generated as a
> message/sip body.
> 
> Henning

I second that idea -- at least as an option in the absence of a Refer-To 
URL.
It also opens the door for nice things like S/MIME.
/sean


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 17:19:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24362
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 17:19:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 028C844363; Fri,  5 Jan 2001 16:20:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id 2744F44336
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 15:10:34 -0500 (EST)
Received: from cowboys (IDENT:root@localhost [127.0.0.1])
	by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id DAA25485
	for <sip@lists.bell-labs.com>; Sat, 6 Jan 2001 03:16:24 -0600
Message-ID: <008001c0775b$816ff020$ea036e3f@dynamicsoft.com>
From: "Dean Willis" <dwillis@dynamicsoft.com>
To: "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [SIP] Draft minutes of SIP WG, IETF49 posted:
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 5 Jan 2001 15:07:22 -0600
Content-Transfer-Encoding: 7bit

I have posted draft minutes of SIP WG IETF49 at:

http://www.softarmor.com/sipwg/meets/ietf49/minutes/draftminutes-sip-49.htm

Please submit comments and corrections ASAP.

Thanks to Tom Taylor  for taking notes and Brian Bascom for helping collate
them into minutes.

--
Dean Willis


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 17:42:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24791
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 17:42:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9F41644362; Fri,  5 Jan 2001 16:43:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 05FD044337
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 16:42:11 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f05Mg3s22991;
	Fri, 5 Jan 2001 16:42:03 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: Rohan Mahy <rohan@cisco.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Solving the REFER retransmit issue
Message-ID: <20010105164103.A12173@fdd.com>
References: <20001229153044.A311@div8.net> <9BF66EBF6BEFD942915B4D4D45C051F3B573@DYN-TX-EXCH-001.dynam <4.1.20010102094413.00cb77d0@imop.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <4.1.20010102094413.00cb77d0@imop.cisco.com>; from rohan@cisco.com on Tue, Jan 02, 2001 at 10:06:47AM -0800
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 5 Jan 2001 16:41:03 -0600

On Tue, Jan 02, 2001 at 10:06:47AM -0800, Rohan Mahy wrote:
> 
> hogwash.  the timing expectations are identical.  attended transfer is
> *HARDLY* an advanced case.   For example: screening your incoming voicemail
> is a more advanced feature which uses more than one primitive working
> together.  if we cripple our primitives now, we will have call flows worthy
> of H.323v1, huge message counts, and the services everyone keeps promising
> will not appear.  (I counted over 100 messages for a fairly straightforward
> call screening example with the REFER, SUB, NTFY method).  God forbid if we
> add manyfolks QoS to any of these flows, or security....
> 
> fundamentally we need to initiate, terminate, move, join, split, and get
> status of call-legs.  THESE are the types of primitives we need.  An
> inherent part of moving call legs is being able to find out what happened;
> it is not optional.
> 
> thanks,
> -rohan
> 

For supervised call transfer, you will have problems 
if you want the remote device to do
the audio mixing.  

If you mix in the local device, then the
only primative you need 
is glueing together the two call legs at the end of
the conference stage.  Thus, you effectively excuse
yourself from the back-to-back UA functionality 
(a.k.a. Rosenberg 3rd party call control).
This is the simple primative I want.  Let us be
able to reduce the number of network devices
the signalling snakes through, thus making the
call more reliable, signaling faster, etc.

As much as I prefer smart end points,
and hate stateful network ones,
I predict remote back-to-back UA's will eventually
be popular, because this is what a PBX is.   
Many of the features are inharently server based.  
Also, If you want to build a reliable system
(and trust me telephony places a high
premium on reliability)  then your 
back-to-back UA PBX will hide everything
from the outside world.  

Using only the basics of SIP has some precedent.  
The best web sites (Yahoo, Amazon, eBay, eGroups, 
McGlen, etc) use simple HTML (no JavaScript).  
The processing and state is in the server.
Testing is much easier.

Now, that I have said this, the obvious question
is how to command the smart back-to-back UA PBX
without using the 12 DTMF keys.  Each feature
is unique.  Try designing call park.

For generalized features,
sending the requests isn't the hard part,
but displaying it to the user is.  Ultimately,
the solution will look more like a text based
web browser in the phone.

--
Rick
rick_dean@3com.com

P.S. Please forgive me if this has already been
discussed on the list.  I have only been following
it until recently via proxy.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan  5 19:53:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26099
	for <sip-archive@odin.ietf.org>; Fri, 5 Jan 2001 19:53:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 52DF144356; Fri,  5 Jan 2001 18:54:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241])
	by lists.bell-labs.com (Postfix) with ESMTP id 393D244337
	for <sip@lists.bell-labs.com>; Fri,  5 Jan 2001 17:37:02 -0500 (EST)
Received: from francislaptop ([208.176.6.221])
 by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9)
 with SMTP id <0G6P00IMPNUN6B@mta5.snfc21.pbi.net> for sip@lists.bell-labs.com;
 Fri,  5 Jan 2001 14:30:23 -0800 (PST)
From: Paul Francis <yoid2000@pacbell.net>
To: sip@lists.bell-labs.com
Reply-To: Paul Francis <paul@francis.com>
Message-id: <008901c07767$ad9a20b0$a7fb10ac@francislaptop>
MIME-version: 1.0
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Priority: 3
Subject: [SIP] question on received tag in via header,
 draft-ietf-sip-rfc2543bis-02.txt
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 05 Jan 2001 14:34:33 -0800
Content-Transfer-Encoding: 7bit


Why is it that the receiver tag in the via header indicate the received
network address but not also the received port (in section 6.47.2
Receiver-tagged Via Header Fields)?

It seems you'd want this too to deal with port translation in a NAT box.
For instance, using the example from section 6.47.2, if you got the
following via header:

     Via: SIP/2.0/UDP 10.0.0.1:5060 ;received=199.172.136.3

but the NAT box at 199.172.136.3 was also doing port translation and used,
say, port 13488, then this would fail to return the packet to the proxy at
10.0.0.1 because the NAT box wouldn't know how to route the packet.

Seems what you'd want instead is:

     Via: SIP/2.0/UDP 10.0.0.1:5060 ;received=199.172.136.3:13488


PF






_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Sat Jan  6 20:26:53 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18990
	for <sip-archive@odin.ietf.org>; Sat, 6 Jan 2001 20:26:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3C5DD44338; Sat,  6 Jan 2001 19:27:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id C5A2444336
	for <sip@lists.bell-labs.com>; Sat,  6 Jan 2001 19:26:16 -0500 (EST)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <CKD5P4FP>; Sat, 6 Jan 2001 17:26:17 -0800
Message-ID: <E79883AEA37FD411A58C00508BAC5F4B2B5C1B@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'SIP List'" <sip@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C07848.D478F850"
Subject: [SIP] Early media replacement.
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 6 Jan 2001 17:26:16 -0800

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_01C07848.D478F850
Content-Type: text/plain;
	charset="windows-1255"


Hi all,

I was reading the open issues from the last IETF BoF and was wondering what
people had in mind to replace early media:

Excerpt of
http://www.softarmor.com/sipwg/meets/ietf49/minutes/openissues-demirtjis.htm
:

---
2. Forget 183s. Use a one way 200 OK and then do a re-INVITE to get both
ways going. What about post-dial delays? Reasons for wanting early media:
Billing issue for PSTN interworking. Not cutting off voice. QoS negotiation
(doing PRACK). If don't care about QoS negotiation, no need to do 183s.
...
Problem: for a lot of calls, dialed DTMFs are collected before the call is
officially up. Requires bi-directional media. 200Ok means bi-directional
media path has been established. It doesn't mean the call has been answered.
For bi-directional, send a 280.

--

[280?? I assume this is meant to say 180]

Ok 200 OK really simply means that session is active. However, for a long
time we have been conceptually/implicitly equatign this to mean that the
remote client/phone/person/terminal has "answered". Which is not necessarily
true. [This reminds of a discussion along time ago about a SIP alarm clock
which is an automated SIP device.] 

When the SIP is being used for establishing live communications channels (eg
session to a "terminal") rather than just as a session initiation protocol
(eg gaming servers), then is there a need to indicate the remote terminal
state? 

This seems to me to be the missing link in why it is so difficult to kick
the early media for VoIP (et al) applications - because there is no way to
differentiate session state from terminal state.

In the above suggestion where a one-way session is established and then a
re-INVITE is used to negiotiate the two-way session when the terminal
answers, SIP provides no mechanism (that I can see) for communicating what
is actually going on with the terminal, eg when to start billing. You could
say that you start billing when there is a two-way media stream but is this
the best way to go about it (ie, tied to media level info)? I don't think
so. For instance, you may want to start billing only when the remote
terminal user answers.

[This whole issue is obviously tied to billing but the solution should not
be aimed be at solving only that sub-space of the problem (IMO). I think the
terminal state information should provide the billing information and not
the other way around!]

Is this the right approach, ie, to separate SIP session establishment state
from implied terminal state?
Is this beyond the scope of the WG? [Since SIP is currently primarily used
for terminal based  communications, perhaps not.]
Is there already a "package" for describing generic terminal status that we
can use for SIP?

I'll be interested to hear what people think.

Regards,

Robert.

-- My opinions are my own and do not necessarily represent those of Nuera
Communications, Inc. -- 

------_=_NextPart_001_01C07848.D478F850
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Early media replacement.</TITLE>
</HEAD>
<BODY>
<BR>

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

<P><FONT SIZE=3D2>I was reading the open issues from the last IETF BoF =
and was wondering what people had in mind to replace early =
media:</FONT>
</P>

<P><FONT SIZE=3D2>Excerpt of =
http://www.softarmor.com/sipwg/meets/ietf49/minutes/openissues-demirtjis=
.htm:</FONT>
</P>

<P><FONT SIZE=3D2>---</FONT>
<BR><FONT SIZE=3D2>2. Forget 183s. Use a one way 200 OK and then do a =
re-INVITE to get both ways going. What about post-dial delays? Reasons =
for wanting early media: Billing issue for PSTN interworking. Not =
cutting off voice. QoS negotiation (doing PRACK). If don't care about =
QoS negotiation, no need to do 183s.</FONT></P>

<P><FONT SIZE=3D2>...</FONT>
<BR><FONT SIZE=3D2>Problem: for a lot of calls, dialed DTMFs are =
collected before the call is officially up. Requires bi-directional =
media. 200Ok means bi-directional media path has been established. It =
doesn't mean the call has been answered. For bi-directional, send a =
280.</FONT></P>

<P><FONT SIZE=3D2>--</FONT>
</P>

<P><FONT SIZE=3D2>[280?? I assume this is meant to say 180]</FONT>
</P>

<P><FONT SIZE=3D2>Ok 200 OK really simply means that session is active. =
However, for a long time we have been conceptually/implicitly equatign =
this to mean that the remote client/phone/person/terminal has =
&quot;answered&quot;. Which is not necessarily true. [This reminds of a =
discussion along time ago about a SIP alarm clock which is an automated =
SIP device.] </FONT></P>

<P><FONT SIZE=3D2>When the SIP is being used for establishing live =
communications channels (eg session to a &quot;terminal&quot;) rather =
than just as a session initiation protocol (eg gaming servers), then is =
there a need to indicate the remote terminal state? </FONT></P>

<P><FONT SIZE=3D2>This seems to me to be the missing link in why it is =
so difficult to kick the early media for VoIP (et al) applications - =
because there is no way to differentiate session state from terminal =
state.</FONT></P>

<P><FONT SIZE=3D2>In the above suggestion where a one-way session is =
established and then a re-INVITE is used to negiotiate the two-way =
session when the terminal answers, SIP provides no mechanism (that I =
can see) for communicating what is actually going on with the terminal, =
eg when to start billing. You could say that you start billing when =
there is a two-way media stream but is this the best way to go about it =
(ie, tied to media level info)? I don't think so. For instance, you may =
want to start billing only when the remote terminal user =
answers.</FONT></P>

<P><FONT SIZE=3D2>[This whole issue is obviously tied to billing but =
the solution should not be aimed be at solving only that sub-space of =
the problem (IMO). I think the terminal state information should =
provide the billing information and not the other way =
around!]</FONT></P>

<P><FONT SIZE=3D2>Is this the right approach, ie, to separate SIP =
session establishment state from implied terminal state?</FONT>
<BR><FONT SIZE=3D2>Is this beyond the scope of the WG? [Since SIP is =
currently primarily used for terminal based&nbsp; communications, =
perhaps not.]</FONT></P>

<P><FONT SIZE=3D2>Is there already a &quot;package&quot; for describing =
generic terminal status that we can use for SIP?</FONT>
</P>

<P><FONT SIZE=3D2>I'll be interested to hear what people think.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

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

<P><FONT SIZE=3D2>-- My opinions are my own and do not necessarily =
represent those of Nuera Communications, Inc. -- </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07848.D478F850--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Sat Jan  6 21:38:54 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20474
	for <sip-archive@odin.ietf.org>; Sat, 6 Jan 2001 21:38:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A584044338; Sat,  6 Jan 2001 20:39:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by lists.bell-labs.com (Postfix) with ESMTP id EE5B044336
	for <sip@lists.bell-labs.com>; Sat,  6 Jan 2001 20:38:24 -0500 (EST)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261)
 id <0G6R00L01TZOSN@firewall.mcit.com> for sip@lists.bell-labs.com; Sun,
 7 Jan 2001 02:38:12 +0000 (GMT)
Received: from pmismtp04.wcomnet.com ([166.38.62.39])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0G6R00I79TZNED@firewall.mcit.com>; Sun,
 07 Jan 2001 02:38:12 +0000 (GMT)
Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258)
 id <0G6R00K01TZNMQ@pmismtp04.wcomnet.com>; Sun,
 07 Jan 2001 02:38:11 +0000 (GMT)
Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0G6R00K01TZMMH@pmismtp04.wcomnet.com>;
 Sun, 07 Jan 2001 02:38:11 +0000 (GMT)
Received: from hsinnreich ([166.44.57.44])
 by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258)
 with SMTP id <0G6R00K08TZ56C@pmismtp04.wcomnet.com>; Sun,
 07 Jan 2001 02:38:04 +0000 (GMT)
From: Henry Sinnreich <henry.sinnreich@wcom.com>
Subject: RE: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]
In-reply-to: <20010105094726.A9558@newman.frascone.com>
To: David Frascone <dave@frascone.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>,
        "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
        Michael Thomas <mat@cisco.com>, SIP List <sip@lists.bell-labs.com>,
        C.T.A.M.deLaat@phys.uu.nl, jrv@interlinknetworks.com
Message-id: <NEBBLDFFKGAJDPBENMDNIEILDGAA.henry.sinnreich@wcom.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 06 Jan 2001 20:38:01 -0600
Content-Transfer-Encoding: 7bit

>But, I *still* don't understand why you would want the TRANSPORT to be
>XML.

I said
>> As for the question why XML/HTTP:

that means HTTP transport.

Henry

-----Original Message-----
From: David Frascone [mailto:dave@frascone.com]
Sent: Friday, January 05, 2001 9:47 AM
To: Henry Sinnreich
Cc: Pat Calhoun; Henning G. Schulzrinne; Michael Thomas; SIP List;
C.T.A.M.deLaat@phys.uu.nl; jrv@interlinknetworks.com
Subject: Re: [aboba@internaut.com: Re: [SIP] draft-calhoun-sip-aaa-req]


> As for the question why XML/HTTP:
>
> ISP services development and operations costs are minimized by using the
> smallest number of protocols and data formats.
> HTTP clearly makes it to the top of the short list for transport.
> XML has countless tools for dummies (like me) and can be displayed with
the
> browser and is thus ideal for testing and prototyping in this fast
changing
> environment. It is has also a large field of applicability. DIAMETER with
> its AVP data formats does not have these advantages - may have its place
as
> mentioned for network access, but is not in the center of the AAA universe
> IMHO. Pushing DIAMETER to be the focus of AAA is not convincing.
>

I'm not sure I follow your reasoning.  I agree that XML is an exelent way
to model data.  But, I have to disagree about it being a good transport.  In
my opinion, AVPs were chosen because the are extensible, and, SMALL.  And,
since they are binary, they do not have to be parsed, but can be manipulated
by pointing a structure at them.

Any of the data transported in AVPs could be *viewed* with an XML viewer
after
a small conversion.  Accounting data could also be sent as XML.  Any XML
payload could be sent inside of AVPs.

But, I *still* don't understand why you would want the TRANSPORT to be
XML.  We are still talking about the TRANSPORT, right?  What is the
reasoning
for having XML on the wire?

<sarcastic hat> I mean, if we are going to use it as the transport, why stop
there?  Why not XML over IP?  XML over ethernet? </sarcastic hat>

Please, If I'm missing something, let me know.  But I am haveing serious
trouble following your need for being able to sniff XML packets on the wire.


Dave Frascone


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Sun Jan  7 10:34:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08452
	for <sip-archive@odin.ietf.org>; Sun, 7 Jan 2001 10:34:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6431844342; Sun,  7 Jan 2001 09:35:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from voyanttech.com (voyantteer-u5.voyanttech.com [63.89.131.5])
	by lists.bell-labs.com (Postfix) with ESMTP id 9326844336
	for <sip@lists.bell-labs.com>; Sat,  6 Jan 2001 19:27:42 -0500 (EST)
Received: by voyanttech.com (CommuniGate Pro PIPE 3.4b3)
  with PIPE id 331717; Sat, 06 Jan 2001 18:27:31 -0700
From: root@voyanttech.com
To: sip@lists.bell-labs.com
X-Mailer: CommuniGate Pro CLI mailer
Message-ID: <auto-000000331717@voyanttech.com>
Subject: [SIP] Rejected Email:
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 06 Jan 2001 18:27:31 -0700

Received: from [204.133.175.127] (HELO aphrodite.systems.cfer.com)
  by voyanttech.com (CommuniGate Pro SMTP 3.4b3)
  with ESMTP id 331715; Sat, 06 Jan 2001 18:27:19 -0700
Received: from ns1.voyanttech.com (ns1.voyanttech.com [192.168.250.33])
	by aphrodite.systems.cfer.com (8.8.8+Sun/8.8.8) with ESMTP id SAA12898;
	Sat, 6 Jan 2001 18:27:19 -0700 (MST)
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ns1.voyanttech.com (8.9.3/8.9.3) with ESMTP id SAA19452;
	Sat, 6 Jan 2001 18:32:45 -0700
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 82FE244339; Sat,  6 Jan 2001 19:27:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id C5A2444336
	for <sip@lists.bell-labs.com>; Sat,  6 Jan 2001 19:26:16 -0500 (EST)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <CKD5P4FP>; Sat, 6 Jan 2001 17:26:17 -0800
Message-ID: <E79883AEA37FD411A58C00508BAC5F4B2B5C1B@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'SIP List'" <sip@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C07848.D478F850"
Subject: [SIP] Early media replacement.
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 6 Jan 2001 17:26:16 -0800

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_01C07848.D478F850
Content-Type: text/plain;
	charset="windows-1255"


Hi all,

I was reading the open issues from the last IETF BoF and was wondering what
people had in mind to replace early media:

Excerpt of
http://www.softarmor.com/sipwg/meets/ietf49/minutes/openissues-demirtjis.htm
:

---
2. Forget 183s. Use a one way 200 OK and then do a re-INVITE to get both
ways going. What about post-dial delays? Reasons for wanting early media:
Billing issue for PSTN interworking. Not cutting off voice. QoS negotiation
(doing PRACK). If don't care about QoS negotiation, no need to do 183s.
...
Problem: for a lot of calls, dialed DTMFs are collected before the call is
officially up. Requires bi-directional media. 200Ok means bi-directional
media path has been established. It doesn't mean the call has been answered.
For bi-directional, send a 280.

--

[280?? I assume this is meant to say 180]

Ok 200 OK really simply means that session is active. However, for a long
time we have been conceptually/implicitly equatign this to mean that the
remote client/phone/person/terminal has "answered". Which is not necessarily
true. [This reminds of a discussion along time ago about a SIP alarm clock
which is an automated SIP device.] 

When the SIP is being used for establishing live communications channels (eg
session to a "terminal") rather than just as a session initiation protocol
(eg gaming servers), then is there a need to indicate the remote terminal
state? 

This seems to me to be the missing link in why it is so difficult to kick
the early media for VoIP (et al) applications - because there is no way to
differentiate session state from terminal state.

In the above suggestion where a one-way session is established and then a
re-INVITE is used to negiotiate the two-way session when the terminal
answers, SIP provides no mechanism (that I can see) for communicating what
is actually going on with the terminal, eg when to start billing. You could
say that you start billing when there is a two-way media stream but is this
the best way to go about it (ie, tied to media level info)? I don't think
so. For instance, you may want to start billing only when the remote
terminal user answers.

[This whole issue is obviously tied to billing but the solution should not
be aimed be at solving only that sub-space of the problem (IMO). I think the
terminal state information should provide the billing information and not
the other way around!]

Is this the right approach, ie, to separate SIP session establishment state
from implied terminal state?
Is this beyond the scope of the WG? [Since SIP is currently primarily used
for terminal based  communications, perhaps not.]
Is there already a "package" for describing generic terminal status that we
can use for SIP?

I'll be interested to hear what people think.

Regards,

Robert.

-- My opinions are my own and do not necessarily represent those of Nuera
Communications, Inc. -- 

------_=_NextPart_001_01C07848.D478F850
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">

FOR ANTI-VIRUS SECURITY, THIS EMAIL HAS BEEN CLEANED.

REASON:
THE ATTACHMENT CONTAINED AN INVALID EXTENSION OF '.
'

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Sun Jan  7 10:35:17 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08469
	for <sip-archive@odin.ietf.org>; Sun, 7 Jan 2001 10:35:16 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 40ADC44348; Sun,  7 Jan 2001 09:35:09 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from voyanttech.com (voyantteer-u5.voyanttech.com [63.89.131.5])
	by lists.bell-labs.com (Postfix) with ESMTP id 852614433E
	for <sip@lists.bell-labs.com>; Sat,  6 Jan 2001 19:28:42 -0500 (EST)
Received: by voyanttech.com (CommuniGate Pro PIPE 3.4b3)
  with PIPE id 331721; Sat, 06 Jan 2001 18:28:31 -0700
From: root@voyanttech.com
To: sip@lists.bell-labs.com
X-Mailer: CommuniGate Pro CLI mailer
Message-ID: <auto-000000331721@voyanttech.com>
Subject: [SIP] Rejected Email:
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 06 Jan 2001 18:28:31 -0700

Received: from [204.133.175.127] (HELO aphrodite.systems.cfer.com)
  by voyanttech.com (CommuniGate Pro SMTP 3.4b3)
  with ESMTP id 331719 for jefe@zeus.voyanttech.com; Sat, 06 Jan 2001 18:28:26 -0700
Received: from ns1.voyanttech.com (ns1.voyanttech.com [192.168.250.33])
	by aphrodite.systems.cfer.com (8.8.8+Sun/8.8.8) with ESMTP id SAA12912
	for <jefe@zeus.voyanttech.com>; Sat, 6 Jan 2001 18:28:26 -0700 (MST)
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ns1.voyanttech.com (8.9.3/8.9.3) with ESMTP id SAA19455
	for <jefe@voyanttech.com>; Sat, 6 Jan 2001 18:33:53 -0700
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 19A444433B; Sat,  6 Jan 2001 19:27:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id C5A2444336
	for <sip@lists.bell-labs.com>; Sat,  6 Jan 2001 19:26:16 -0500 (EST)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <CKD5P4FP>; Sat, 6 Jan 2001 17:26:17 -0800
Message-ID: <E79883AEA37FD411A58C00508BAC5F4B2B5C1B@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'SIP List'" <sip@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C07848.D478F850"
Subject: [SIP] Early media replacement.
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 6 Jan 2001 17:26:16 -0800

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_01C07848.D478F850
Content-Type: text/plain;
	charset="windows-1255"


Hi all,

I was reading the open issues from the last IETF BoF and was wondering what
people had in mind to replace early media:

Excerpt of
http://www.softarmor.com/sipwg/meets/ietf49/minutes/openissues-demirtjis.htm
:

---
2. Forget 183s. Use a one way 200 OK and then do a re-INVITE to get both
ways going. What about post-dial delays? Reasons for wanting early media:
Billing issue for PSTN interworking. Not cutting off voice. QoS negotiation
(doing PRACK). If don't care about QoS negotiation, no need to do 183s.
...
Problem: for a lot of calls, dialed DTMFs are collected before the call is
officially up. Requires bi-directional media. 200Ok means bi-directional
media path has been established. It doesn't mean the call has been answered.
For bi-directional, send a 280.

--

[280?? I assume this is meant to say 180]

Ok 200 OK really simply means that session is active. However, for a long
time we have been conceptually/implicitly equatign this to mean that the
remote client/phone/person/terminal has "answered". Which is not necessarily
true. [This reminds of a discussion along time ago about a SIP alarm clock
which is an automated SIP device.] 

When the SIP is being used for establishing live communications channels (eg
session to a "terminal") rather than just as a session initiation protocol
(eg gaming servers), then is there a need to indicate the remote terminal
state? 

This seems to me to be the missing link in why it is so difficult to kick
the early media for VoIP (et al) applications - because there is no way to
differentiate session state from terminal state.

In the above suggestion where a one-way session is established and then a
re-INVITE is used to negiotiate the two-way session when the terminal
answers, SIP provides no mechanism (that I can see) for communicating what
is actually going on with the terminal, eg when to start billing. You could
say that you start billing when there is a two-way media stream but is this
the best way to go about it (ie, tied to media level info)? I don't think
so. For instance, you may want to start billing only when the remote
terminal user answers.

[This whole issue is obviously tied to billing but the solution should not
be aimed be at solving only that sub-space of the problem (IMO). I think the
terminal state information should provide the billing information and not
the other way around!]

Is this the right approach, ie, to separate SIP session establishment state
from implied terminal state?
Is this beyond the scope of the WG? [Since SIP is currently primarily used
for terminal based  communications, perhaps not.]
Is there already a "package" for describing generic terminal status that we
can use for SIP?

I'll be interested to hear what people think.

Regards,

Robert.

-- My opinions are my own and do not necessarily represent those of Nuera
Communications, Inc. -- 

------_=_NextPart_001_01C07848.D478F850
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">

FOR ANTI-VIRUS SECURITY, THIS EMAIL HAS BEEN CLEANED.

REASON:
THE ATTACHMENT CONTAINED AN INVALID EXTENSION OF '.
'

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Sun Jan  7 12:42:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09061
	for <sip-archive@odin.ietf.org>; Sun, 7 Jan 2001 12:42:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 897BE44338; Sun,  7 Jan 2001 11:43:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pallas.host4u.net (pallas.host4u.net [216.71.64.48])
	by lists.bell-labs.com (Postfix) with ESMTP id A5F3F44336
	for <sip@lists.bell-labs.com>; Sun,  7 Jan 2001 11:42:49 -0500 (EST)
Received: from KAGOOROQ77G3M6 ([212.199.50.10])
	by pallas.host4u.net (8.8.5/8.8.5) with SMTP id LAA05699
	for <sip@lists.bell-labs.com>; Sun, 7 Jan 2001 11:23:31 -0600
From: "Dan Sahar" <dans@kagoor.com>
To: "Sip" <sip@lists.bell-labs.com>
Message-ID: <DMEFILDNOHJNADOFDHCCOEAPCCAA.dans@kagoor.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0056_01C078E2.A1C5A300"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Subject: [SIP] Status of draft-ietf-sip-session-timer-04.txt
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 7 Jan 2001 19:47:13 +0200

This is a multi-part message in MIME format.

------=_NextPart_000_0056_01C078E2.A1C5A300
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi,

I wanted to inquire as to the status of draft-ietf-sip-session-timer-04.txt.
How widely implemented is this extension to the protocol?
Also, if it is not imlemented, what are my other options to time out a
sesssion?
Regards,

Dan Sahar
Kagoor Networks Ltd.
Tel: 972-9-9565333 ext. 221
E-mail: mailto:dans@kagoor.com
Web: www.kagoor.com
______________________________
"..he not busy being born is busy dying."
~Bob Dylan




------=_NextPart_000_0056_01C078E2.A1C5A300
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D179164317-07012001>Hi,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D179164317-07012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D179164317-07012001>I =
wanted to inquire=20
as to the status of <SPAN=20
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: =
HE">draft-ietf-sip-session-timer-04.txt.</SPAN></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D179164317-07012001><SPAN=20
style=3D"FONT-FAMILY: 'Times New Roman'; FONT-SIZE: 12pt; =
mso-fareast-font-family: 'MS Mincho'; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: HE">How=20
widely implemented is this extension to the =
protocol?</SPAN></SPAN></FONT></DIV>
<DIV><SPAN class=3D179164317-07012001>Also, if it is not imlemented, =
what are my=20
other options to time out a sesssion?</SPAN></DIV>
<P><FONT face=3DArial size=3D2>Regards,</FONT></P>
<P><FONT size=3D2><FONT face=3DArial>Dan =
Sahar<BR><STRONG></FONT></FONT><FONT=20
face=3DArial size=3D2>Kagoor Networks Ltd.<BR></FONT></STRONG><FONT =
face=3DArial=20
size=3D2>Tel: 972-9-9565333 ext. 221<BR>E-mail: </FONT><A=20
href=3D"mailto:E-mail:mailto:dans@kagoor.com"><FONT face=3DArial=20
size=3D2>mailto:dans@kagoor.com</FONT></A><BR><FONT face=3DArial =
size=3D2>Web:=20
</FONT><A href=3D"http://www.kagoor.com/"><FONT color=3D#0000ff =
face=3DArial=20
size=3D2>www.kagoor.com</FONT></A><FONT size=3D2><BR><FONT=20
face=3DArial>______________________________<BR></FONT></FONT><FONT=20
face=3DArial><FONT size=3D1>"..he not busy being born is busy dying." =
<BR>~Bob=20
Dylan<BR><!--  END lyrics  --><!--  spacer  --></FONT></FONT></P>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0056_01C078E2.A1C5A300--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Sun Jan  7 18:23:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10531
	for <sip-archive@odin.ietf.org>; Sun, 7 Jan 2001 18:23:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5B65444338; Sun,  7 Jan 2001 17:24:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 7A47244337
	for <sip@lists.bell-labs.com>; Sun,  7 Jan 2001 17:23:50 -0500 (EST)
Received: from po216.warszawa.cvx.ppp.tpnet.pl ([213.76.110.216]:2222 "EHLO
        elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP
	id <S225689AbRAGXXJ>; Mon, 8 Jan 2001 00:23:09 +0100
Message-ID: <3A57F554.6FFF21E7@elka.pw.edu.pl>
From: "Piotr S. Kossowski" <P.Kossowski@elka.pw.edu.pl>
Organization: Warsaw University of Technology - Institute of Telecommunications
X-Mailer: Mozilla 4.7 [pl] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: SIP discussion list <sip@lists.bell-labs.com>
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
Subject: [SIP] Correct copying 'tag's between 'To' and 'From' ?...
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 07 Jan 2001 05:49:24 +0100
Content-Transfer-Encoding: 8bit

Dear All,

I have doubts with copying 'tag's in subsequent request.
According to 11.4 of the 2543bis-02:

"Regardless of whether the caller or callee is generating the new request,
the header fields in the request are set as follows. For the desired call 
leg, the To header field is set to the remote address, and  the From 
header field is set to the local address (both including any tags)."

and 6.43:

"A UAS or redirect server MUST add a “tag” parameter for all final 
responses for all transactions within a call leg."

let's consider:

(Caller - A)  (Callee - B)

1.   ----- INVITE --->    (To: hostB , From: HostA)	
2.   <----- 200 -----     (To: hostB;tag=123 , From: hostA)	

after while:

3.   <---- BYE ------  (To: hostA, From: hostB;tag=123)
4.   ----- 200 ------> (To: hostA;tag=abc , From: hostB;tag=123)

Is this correct ? I mean: 

Are tags added to responses not for INVITE ?

Is this To-From swap correct ?

Would something change if , instead of BYE, Callee sent INVITE 
(actually, re-INVITE) ?

If above is correct, I wonder what next (after re-INVITE in 3.
instead of BYE):

5.   ----- INVITE --->    (To: hostB;tag=123 , From: hostA;tag=abc)	
6.   <----- 200 -----     (To: hostB;tag=123 , From: hostA;tag=abc)

Should Callee reply with 4xx if 5. INVITE did NOT contain 'tag' in 'From'?



If you have any idea, comments are welcome...

Regards,
Piotr



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 02:07:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28063
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 02:07:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5B2B744346; Mon,  8 Jan 2001 01:08:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 6EB7B4433A
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 01:07:03 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA02018;
	Mon, 8 Jan 2001 02:09:38 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBVGY>; Mon, 8 Jan 2001 02:03:56 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAFE5@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Dan Sahar'" <dans@kagoor.com>, Sip <sip@lists.bell-labs.com>
Subject: RE: [SIP] Status of draft-ietf-sip-session-timer-04.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 02:03:54 -0500


  
-----Original Message-----
>From: Dan Sahar [mailto:dans@kagoor.com]
>Sent: Sunday, January 07, 2001 12:47 PM
>To: Sip
>Subject: [SIP] Status of draft-ietf-sip-session-timer-04.txt
>
>
>Hi,
>
>I wanted to inquire as to the status of
draft-ietf-sip-session-timer-04.txt.

It is complete, and awaiting a working group last call.

>How widely implemented is this extension to the protocol?

There are definitely implementations. Of all the sip extensions, I believe
this one to be amongst the most commonly implemented. I do not have concrete
data on what percentage of sip implementations also have session timer.

>Also, if it is not imlemented, what are my other options to time out a
sesssion?

The other options for session timeout are active "pings", using something
like OPTIONS, or RTCP. OPTIONS can detect if a UA is alive or not, but
cannot determine whether a session is active. RTCP has periodic feedback
roughly every 5 seconds that can be used for liveness. However, not all SIP
sessions need be RTP. People also wanted a sip level session timer, rather
than relying on the underlying media.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 02:15:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28105
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 02:15:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A879B44353; Mon,  8 Jan 2001 01:16:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id CF5CF44352
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 01:15:01 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA02065;
	Mon, 8 Jan 2001 02:17:26 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBVHC>; Mon, 8 Jan 2001 02:11:44 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAFE6@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Piotr S. Kossowski'" <P.Kossowski@elka.pw.edu.pl>,
        SIP discussion list <sip@lists.bell-labs.com>
Subject: RE: [SIP] Correct copying 'tag's between 'To' and 'From' ?...
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-2"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 02:11:43 -0500

Comments below.




> -----Original Message-----
> From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl]
> Sent: Saturday, January 06, 2001 11:49 PM
> To: SIP discussion list
> Subject: [SIP] Correct copying 'tag's between 'To' and 'From' ?...
>
>
> Dear All,
>
> I have doubts with copying 'tag's in subsequent request.
> According to 11.4 of the 2543bis-02:
>
> "Regardless of whether the caller or callee is generating the
> new request,
> the header fields in the request are set as follows. For the
> desired call
> leg, the To header field is set to the remote address, and  the From
> header field is set to the local address (both including any tags)."
>
> and 6.43:
>
> "A UAS or redirect server MUST add a "tag" parameter for all final
> responses for all transactions within a call leg."
>
> let's consider:
>
> (Caller - A)  (Callee - B)
>
> 1.   ----- INVITE --->    (To: hostB , From: HostA)  
> 2.   <----- 200 -----     (To: hostB;tag=123 , From: hostA)  
>
> after while:
>
> 3.   <---- BYE ------  (To: hostA, From: hostB;tag=123)
> 4.   ----- 200 ------> (To: hostA;tag=abc , From: hostB;tag=123)
>
> Is this correct ? I mean:
>
> Are tags added to responses not for INVITE ?

Not if you can avoid it. This issue was discussed at IETF. It is easily
solved by mandating tags in the From field of the initial INVITE. If this is
done, the BYE in 3 already has tags in the To and From, and thus the
response in 4 would not need to add one.

Unfortunately, mandatory From tags are new in rfc2543bis. Thus, an
implementation may need to deal with an older UA that decides to add a tag
in the middle of a call, as above. The conclusion at IETF was not to mandate
that a UA have to handle the addition of a new remote tag mid-call. Rather,
the spec would recommend some kind of reasonable graceful behavior, as a
SHOULD or MAY.


>
> Is this To-From swap correct ?

Yes.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 02:27:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28136
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 02:27:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7A2C94435C; Mon,  8 Jan 2001 01:28:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 1E71F44359
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 01:27:06 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA02094;
	Mon, 8 Jan 2001 02:29:31 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBVH2>; Mon, 8 Jan 2001 02:23:50 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAFE7@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Fairlie-Cuninghame, Robert'" <rfairlie@nuera.com>,
        "'SIP List'" <sip@lists.bell-labs.com>
Subject: RE: [SIP] Early media replacement.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="windows-1255"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 02:23:46 -0500



  
-----Original Message-----
>From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
>Sent: Saturday, January 06, 2001 8:26 PM
>To: 'SIP List'
>Subject: [SIP] Early media replacement.
>
>
>
>
>Hi all, 
>I was reading the open issues from the last IETF BoF and was wondering what
people had in 
>mind to replace early media: 
>
>Excerpt of
http://www.softarmor.com/sipwg/meets/ietf49/minutes/openissues-demirtjis.htm
: 
>--- 
>2. Forget 183s. Use a one way 200 OK and then do a re-INVITE to get both
ways going. What 
>about post-dial delays? Reasons for wanting early media: Billing issue for
PSTN 
>interworking. Not cutting off voice. QoS negotiation (doing PRACK). If
don't care about QoS 
>negotiation, no need to do 183s.
>... 
>Problem: for a lot of calls, dialed DTMFs are collected before the call is
officially up. 
>Requires bi-directional media. 200Ok means bi-directional media path has
been established. 
>It doesn't mean the call has been answered. For bi-directional, send a 280.
>-- 
>[280?? I assume this is meant to say 180] 
>Ok 200 OK really simply means that session is active. However, for a long
time we have been 
>conceptually/implicitly equatign this to mean that the remote
client/phone/person/terminal 
>has "answered". Which is not necessarily true. [This reminds of a
discussion along time ago 
>about a SIP alarm clock which is an automated SIP device.] 

Nothing radical was agreed upon at this discussion. Let me clarify.

We discussed the whole early media issue, and were concerned about the
increasing complexity it was causing. We discussed the possibility of
recommending you always send a 200 OK when you want to establish a session
(independently of whether the phone was answered or not), but there are
simply too many serious issues with this, many of which were visited during
the old DCS discussions surrounding the two phase invite. The billing and
interop issues you mention are among them.

So, all that was agreed upon was to simplify life for the minimal rfc2543
client. All the stuff regarding signaling support for early media (handling
of 183, dealing with SDP in 183, the resulting needed for provisional
response reliability, preconditions, etc.) would not be in the base spec.
Now, that doesn't mean that a UA doesn't need to support early media.
Rather, an rfc2543-only UA would have to be prepared to receive and play
media immediately after sending INVITE. If it wanted enhanced security
services, QoS for that early media, bidirectional early media, and so on, it
would have to support some of the extensions. 

So, that old 183 draft which has expired will be revived, and in it will be
the stuff for handling basic early media at the SDP/SIP level.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 02:31:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28186
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 02:31:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6972A44364; Mon,  8 Jan 2001 01:32:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 398BF4435C
	for <SIP@lists.bell-labs.com>; Mon,  8 Jan 2001 01:31:10 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA02122;
	Mon, 8 Jan 2001 02:33:42 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBVH3>; Mon, 8 Jan 2001 02:28:01 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAFE8@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'james jack'" <sipjames@yahoo.com>, SIP@lists.bell-labs.com,
        schulzrinne@cs.columbia.edu, schooler@cs.caltech.edu
Cc: HenrHenry.Sinnreich@wcom.com, Jonathan Rosenberg <jdrosen@dynamicsoft.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] RE: Consultation on Multicast
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 02:27:59 -0500



 

> -----Original Message-----
> From: james jack [mailto:sipjames@yahoo.com]
> Sent: Friday, January 05, 2001 7:52 AM
> To: SIP@lists.bell-labs.com; schulzrinne@cs.columbia.edu;
> schooler@cs.caltech.edu
> Cc: HenrHenry.Sinnreich@wcom.com; jdrosen@dynamicsoft.com
> Subject: Consultation on Multicast
> 
> 
> Dear All:
>    I have one question to consult, On page 57 of
> RFC2543bis02(PDF format),In section "6.46.1 Requests",
> 
> the description on Via, which describes
> "A client that sends a request to a multicast address
> MUST add the "maddr" parameter to its Via header
> field, and SHOULD add the "ttl" parameter. (In that
> case, the maddr parameter SHOULD contain the
> destination multicast address, although under
> exceptional circumstances it MAY contain a unicast
> address.)"
> 
>   But on page 81, in section "12.3.1 Proxying
> Requests", which describes
> "A Proxy server MUSTNOT forward a request to a
> multicast group which already appears in any of the
> Via headers."
>    Then I have one doubt, if a client send a request
> to a multicast group, if this request is passed
> through one proxy, then this proxy will not forward
> this request according to the previous description!
>    Is that right?

No, it is not. This is not what the text says. The text says that
a proxy does not forward a request TO A MULTICAST GROUP that already
appears in the via header. This means that every time a request is
forwarded to a multicast group, it must be a different one than previously
used.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 02:35:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28202
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 02:35:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C80E444350; Mon,  8 Jan 2001 01:36:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 5D86744346
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 01:35:57 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA02155;
	Mon, 8 Jan 2001 02:38:27 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBVHT>; Mon, 8 Jan 2001 02:32:45 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAFE9@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Jon.Peterson@Level3.com'" <Jon.Peterson@Level3.com>,
        eburger@snowshore.com, sip@lists.bell-labs.com
Subject: RE: [SIP] SIP App Components
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 02:32:44 -0500



 

> -----Original Message-----
> From: Jon.Peterson@Level3.com [mailto:Jon.Peterson@Level3.com]
> -----Original Message-----
> From: Eric Burger [mailto:eburger@snowshore.com]
> Sent: Thursday, January 04, 2001 4:58 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] SIP App Components
> 
> 
> The SIP App Components infrastructure assumes that the SIP 
> UA's understand
> multipart MIME body parts.  This is a MAY in bis 02 (Section 8.2).

Where in the app components document does it assume this? None of the
interfaces require multipart. I think we might have mentioned talking to a
voicexml media server by passing the original VoiceXML in the body of the
SIP INVITE; however, thats only one of the options. The best one, IMHO, is
to pass the URL for the voicexml script in a sip header (Call-Info or
something).

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 02:42:27 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28262
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 02:42:27 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CE6EF44372; Mon,  8 Jan 2001 01:41:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 5336044371
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 01:40:13 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA02191;
	Mon, 8 Jan 2001 02:42:09 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBVH6>; Mon, 8 Jan 2001 02:36:27 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AAFEA@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Vijay Gurbani'" <vkg@lucent.com>,
        Deepak Mohan <deepakwarrier@rediffmail.com>
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Canceling BYE
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 02:36:26 -0500



 

> -----Original Message-----
> From: Vijay Gurbani [mailto:vkg@lucent.com]
> Sent: Thursday, January 04, 2001 1:34 PM
> To: Deepak Mohan
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] Canceling BYE
> 
> 
> Deepak Mohan wrote:
> > 
> > The draft-ietf-sip-rfc2543bis-02 does not say anything 
> about a CANCEL 
> > being used to cancel a BYE. Should this be allowed? I don't 
> think very 
> > many protocols allow a 'Release' message to be canceled.
> 
> If a UAS gets a CANCEL to a non-INVITE request before it has 
> generated a 
> final response, the request can effectively be canceled 
> (although, as you
> point out, what is the result of CANCEL'ing a BYE -- does 
> that mean that
> the session should NOT be torn down?).

If you honor the CANCEL, you would basically undo whatever you have done to
the
point where its as if you never received the message being cancelled. So,
yes,
if you get a CANCEL for a BYE, and the UAS decides to honor it, it would no
longer
consider the call terminated. The BYE would be answered by a 487, and the
CANCEL with a 200. 

However, this is really not useful. Its a lot of work for a UAS for no gain.
I suspect all UASs answer a BYE immediately, so that in practice, the CANCEL
will always be a no-op, as the final response to the BYE has already been
sent.

-Jonathan R.


---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 02:53:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28285
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 02:53:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0E8754435A; Mon,  8 Jan 2001 01:54:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lists.bell-labs.com (Postfix) with ESMTP id D1E1144353
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 01:53:54 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f087rU423930;
	Mon, 8 Jan 2001 08:53:31 +0100 (MET)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.40])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA06924;
	Mon, 8 Jan 2001 09:53:30 +0200 (EET)
Message-ID: <3A5971D6.5EC04475@lmf.ericsson.se>
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'Vijay Gurbani'" <vkg@lucent.com>,
        Deepak Mohan <deepakwarrier@rediffmail.com>
Subject: Re: [SIP] Canceling BYE
References: <B65B4F8437968F488A01A940B21982BF9AAFEA@DYN-EXCH-001.dynamicsoft.com>
Content-Type: multipart/mixed;
 boundary="------------25889D1E530C880FF6E32582"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 08 Jan 2001 09:52:54 +0200

This is a multi-part message in MIME format.
--------------25889D1E530C880FF6E32582
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

Especially if you have a PSTN/SIP GW, I guess you will have to answer to
the BYE immediately, and then ignore any possible CANCEL, because once
you start tearing down a PSTN connection you don't "undo" it just like
that...

Regards,

Christer Holmberg
Ericsson Finland



Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Vijay Gurbani [mailto:vkg@lucent.com]
> > Sent: Thursday, January 04, 2001 1:34 PM
> > To: Deepak Mohan
> > Cc: sip@lists.bell-labs.com
> > Subject: Re: [SIP] Canceling BYE
> >
> >
> > Deepak Mohan wrote:
> > >
> > > The draft-ietf-sip-rfc2543bis-02 does not say anything
> > about a CANCEL
> > > being used to cancel a BYE. Should this be allowed? I don't
> > think very
> > > many protocols allow a 'Release' message to be canceled.
> >
> > If a UAS gets a CANCEL to a non-INVITE request before it has
> > generated a
> > final response, the request can effectively be canceled
> > (although, as you
> > point out, what is the result of CANCEL'ing a BYE -- does
> > that mean that
> > the session should NOT be torn down?).
> 
> If you honor the CANCEL, you would basically undo whatever you have done to
> the
> point where its as if you never received the message being cancelled. So,
> yes,
> if you get a CANCEL for a BYE, and the UAS decides to honor it, it would no
> longer
> consider the call terminated. The BYE would be answered by a 487, and the
> CANCEL with a 200.
> 
> However, this is really not useful. Its a lot of work for a UAS for no gain.
> I suspect all UASs answer a BYE immediately, so that in practice, the CANCEL
> will always be a no-op, as the final response to the BYE has already been
> sent.
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
--------------25889D1E530C880FF6E32582
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------25889D1E530C880FF6E32582--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 02:59:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28303
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 02:59:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 78B1C4437A; Mon,  8 Jan 2001 02:00:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id A36E84436C
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 01:59:55 -0500 (EST)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <CKD5P4LQ>; Sun, 7 Jan 2001 23:59:54 -0800
Message-ID: <E79883AEA37FD411A58C00508BAC5F4B2B5C22@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'SIP List'" <sip@lists.bell-labs.com>
Subject: RE: [SIP] Early media replacement.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C07948.F88780D0"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 7 Jan 2001 23:59:48 -0800

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_01C07948.F88780D0
Content-Type: text/plain;
	charset="windows-1255"


> 
> Nothing radical was agreed upon at this discussion. Let me clarify.
> 
> We discussed the whole early media issue, and were concerned about the
> increasing complexity it was causing. We discussed the possibility of
> recommending you always send a 200 OK when you want to 
> establish a session
> (independently of whether the phone was answered or not), but 
> there are
> simply too many serious issues with this, many of which were 
> visited during
> the old DCS discussions surrounding the two phase invite. The 
> billing and
> interop issues you mention are among them.
> 
> So, all that was agreed upon was to simplify life for the 
> minimal rfc2543
> client. All the stuff regarding signaling support for early 
> media (handling
> of 183, dealing with SDP in 183, the resulting needed for provisional
> response reliability, preconditions, etc.) would not be in 
> the base spec.
> Now, that doesn't mean that a UA doesn't need to support early media.
> Rather, an rfc2543-only UA would have to be prepared to 
> receive and play
> media immediately after sending INVITE. If it wanted enhanced security
> services, QoS for that early media, bidirectional early 
> media, and so on, it
> would have to support some of the extensions. 
> 
> So, that old 183 draft which has expired will be revived, and 
> in it will be
> the stuff for handling basic early media at the SDP/SIP level.
> 

There are other problems with deprecating early media by using re-INVITE.
Consider the case where an INVITE request is forked by a proxy to both a SIP
desktop client and a PSTn gateway. If the gateway immediately sends a 200 OK
on receipt of an INVUITE (with a one-way SDP body to relay the remote
ringback) then the desktop client will never get a chance to answer the
call. Between two PSTN gateways you will have a race condition.

Robert.

-- My opinions are my own and should not be taken as representing those of
Nuera Communications, Inc. -- 

------_=_NextPart_001_01C07948.F88780D0
Content-Type: text/html;
	charset="windows-1255"
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=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [SIP] Early media replacement.</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Nothing radical was agreed upon at this =
discussion. Let me clarify.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; We discussed the whole early media issue, and =
were concerned about the</FONT>
<BR><FONT SIZE=3D2>&gt; increasing complexity it was causing. We =
discussed the possibility of</FONT>
<BR><FONT SIZE=3D2>&gt; recommending you always send a 200 OK when you =
want to </FONT>
<BR><FONT SIZE=3D2>&gt; establish a session</FONT>
<BR><FONT SIZE=3D2>&gt; (independently of whether the phone was =
answered or not), but </FONT>
<BR><FONT SIZE=3D2>&gt; there are</FONT>
<BR><FONT SIZE=3D2>&gt; simply too many serious issues with this, many =
of which were </FONT>
<BR><FONT SIZE=3D2>&gt; visited during</FONT>
<BR><FONT SIZE=3D2>&gt; the old DCS discussions surrounding the two =
phase invite. The </FONT>
<BR><FONT SIZE=3D2>&gt; billing and</FONT>
<BR><FONT SIZE=3D2>&gt; interop issues you mention are among =
them.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So, all that was agreed upon was to simplify =
life for the </FONT>
<BR><FONT SIZE=3D2>&gt; minimal rfc2543</FONT>
<BR><FONT SIZE=3D2>&gt; client. All the stuff regarding signaling =
support for early </FONT>
<BR><FONT SIZE=3D2>&gt; media (handling</FONT>
<BR><FONT SIZE=3D2>&gt; of 183, dealing with SDP in 183, the resulting =
needed for provisional</FONT>
<BR><FONT SIZE=3D2>&gt; response reliability, preconditions, etc.) =
would not be in </FONT>
<BR><FONT SIZE=3D2>&gt; the base spec.</FONT>
<BR><FONT SIZE=3D2>&gt; Now, that doesn't mean that a UA doesn't need =
to support early media.</FONT>
<BR><FONT SIZE=3D2>&gt; Rather, an rfc2543-only UA would have to be =
prepared to </FONT>
<BR><FONT SIZE=3D2>&gt; receive and play</FONT>
<BR><FONT SIZE=3D2>&gt; media immediately after sending INVITE. If it =
wanted enhanced security</FONT>
<BR><FONT SIZE=3D2>&gt; services, QoS for that early media, =
bidirectional early </FONT>
<BR><FONT SIZE=3D2>&gt; media, and so on, it</FONT>
<BR><FONT SIZE=3D2>&gt; would have to support some of the extensions. =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So, that old 183 draft which has expired will =
be revived, and </FONT>
<BR><FONT SIZE=3D2>&gt; in it will be</FONT>
<BR><FONT SIZE=3D2>&gt; the stuff for handling basic early media at the =
SDP/SIP level.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>There are other problems with deprecating early media =
by using re-INVITE. Consider the case where an INVITE request is forked =
by a proxy to both a SIP desktop client and a PSTn gateway. If the =
gateway immediately sends a 200 OK on receipt of an INVUITE (with a =
one-way SDP body to relay the remote ringback) then the desktop client =
will never get a chance to answer the call. Between two PSTN gateways =
you will have a race condition.</FONT></P>

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

<P><FONT SIZE=3D2>-- My opinions are my own and should not be taken as =
representing those of Nuera Communications, Inc. -- </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07948.F88780D0--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 04:51:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28816
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 04:51:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E927144363; Mon,  8 Jan 2001 03:52:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from nwcst276.netaddress.usa.net (nwcst276.netaddress.usa.net [204.68.23.21])
	by lists.bell-labs.com (Postfix) with SMTP id B51AC44357
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 03:51:03 -0500 (EST)
Received: (qmail 8838 invoked by uid 60001); 8 Jan 2001 09:50:51 -0000
Message-ID: <20010108095051.8837.qmail@nwcst276.netaddress.usa.net>
Received: from 204.68.23.21 by nwcst276 for [203.197.178.247] via web-mailer(34FM.0700.15.02) on Mon Jan  8 09:50:51 GMT 2001
From: Nishith Chudasama <nishith76@usa.net>
To: sip@lists.bell-labs.com
X-Mailer: USANET web-mailer (34FM.0700.15.02)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Subject: [SIP] REGISTRAR functions.
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 8 Jan 2001 02:50:51 MST
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA28816

Following are the queries regarding SIP REGISTRAR implementation. Kindly let
me know if anybody has the solution.....

1. Where can I get the specifications to develop a SIP Registrar?

2. For a particular USER registration, what all information from the REGISTER
request should be stored by Registrar?(Till the registration expires...)

3. If the REGISTRAR and Location server are not co-located, How and what to
inform the Location server following a REGISTER request from a User?

4. What are the messages exchanged between a SIP proxy/Redirect server and a
Location server/Registrar?

Waiting for the replies....
Regards,
Nishith.

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 05:06:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28944
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 05:06:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D44B94434C; Mon,  8 Jan 2001 04:07:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id 4095A44341
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 04:07:00 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 8 Jan 2001 10:06:48 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id KAA11854; Mon, 8 Jan 2001 10:05:30 GMT
From: "Jo Hornsby" <jhornsby@ubiquity.net>
To: "Paul Francis" <paul@francis.com>, <sip@lists.bell-labs.com>
Subject: RE: [SIP] question on received tag in via header,draft-ietf-sip-rfc2543bis-02.txt
Message-ID: <000d01c0795a$880d1470$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-reply-to: <008901c07767$ad9a20b0$a7fb10ac@francislaptop>
Importance: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 10:05:30 -0000
Content-Transfer-Encoding: 7bit

> Why is it that the receiver tag in the via header indicate the received
> network address but not also the received port (in section 6.47.2
> Receiver-tagged Via Header Fields)?

In a nutshell: the port is generally not considered useful since
just because a client sends from a particular port, it doesn't
mean that it's also listening on that port.

(I vote that this becomes a FAQ.)

Cheers,


 - Jo.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 05:09:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28976
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 05:09:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4EA894437F; Mon,  8 Jan 2001 04:10:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from www0q.netaddress.usa.net (www0q.netaddress.usa.net [204.68.24.46])
	by lists.bell-labs.com (Postfix) with SMTP id 6FA9944379
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 04:09:24 -0500 (EST)
Received: (qmail 2236 invoked by uid 60001); 8 Jan 2001 10:09:12 -0000
Message-ID: <20010108100912.2235.qmail@www0q.netaddress.usa.net>
Received: from 204.68.24.46 by www0q for [203.197.178.247] via web-mailer(34FM.0700.15.02) on Mon Jan  8 10:09:12 GMT 2001
From: Nishith Chudasama <nishith76@usa.net>
To: sip@lists.bell-labs.com
Cc: vijethd@rediffmail.com
X-Mailer: USANET web-mailer (34FM.0700.15.02)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Subject: [SIP] DNS Lookup
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 8 Jan 2001 03:09:12 MST
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA28976

Hi all,

Can anybody let me know if there is some readymade piece of code available on
the net for DNS queries for SIP clients/Servers.

If not, can anybody point to the document specifying the procedure for doing
this?

Thanks in Advance.
Regards,
Nishith

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 05:16:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29047
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 05:16:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B5FB744386; Mon,  8 Jan 2001 04:17:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60])
	by lists.bell-labs.com (Postfix) with ESMTP id A67A744385
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 04:16:10 -0500 (EST)
Received: from cvis01.gpt.co.uk (unverified) by cvis28.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc363f43c50fa5067de@cvis28.marconicomms.com>;
 Mon, 8 Jan 2001 10:15:57 +0000
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-30) id KAA14818; Mon, 8 Jan 2001 10:15:56 GMT
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 802569CE.00385BE9 ; Mon, 8 Jan 2001 10:15:35 +0000
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Keith Robinson" <Keith.Robinson@marconi.com>
To: Steve Levy <stlevy@cisco.com>
Cc: sip@lists.bell-labs.com
Message-ID: <802569CE.00385A56.00@marconicomms.com>
Subject: Re: [SIP] Overlap Sending
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 10:15:41 +0000



Yes, this is the type of case I have in mind. The question I have is what are
the subsequent INVITES; are they

a) New INVITES, on a new Call-Id containing the original digits (from original
INVITE) + subsequent digits ?

or

b) re-INVITES containing only subsequent digits ?

or

c) re-INVITES containing original digits + subsequent digits ?

The sending UAs I referred to in my previous note are those that sit in PSTN/SIP
gateways,
not necessarily an originating UA sitting on someones desktop.

So, the question applies as much to these interworking UAs for constructing
the subsequent INVITEs as well as to receiving UAs for interpreting them.

Regards,

K. Robinson.







Steve Levy <stlevy@cisco.com> on 05/01/2001 22:32:00
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:      Keith Robinson/MAIN/MC1@MCMAIN,                     
          sip@lists.bell-labs.com                             
                                                              
 cc:                                                          
                                                              
                                                              
                                                              
 Subject: Re: [SIP] Overlap Sending                           
                                                              







Hi Keith,

I was wondering if in considering overlap sending issues and SIP if you were
considering the case of overlap sending across multiple networks with variable
length digits.

In this case, in order to avoid post dial delay, the digits need to be passed
through the networks to the final destiantion network prior to end of dial
(since the destination network is the only network that knows how many digits
are required). So in effect there may be additional digits sent after an INVITE
has been received and sent downstream to the callee.

Thanks,
Steve


At 03:50 PM 1/5/01 +0000, Keith Robinson wrote:
>
>
>I have the following query regarding overlap sending as defined in
>rfc2543bis-02:
>
>Section 4.2.1 states the following:
>
>"...the UAS compares the Request-URI with Request-URI of the previous INVITE
>request
>for the same Call-Id. If the Request-URI  contains additional digits in the
>'user' part, the UAS
>treats the INVITE as adding additional digits to the original dialed string."
>
>This appears to imply that the subsequent INVITE contains the original dialled
>string plus the
>additional digits; if this is the case, then there is no need for the UAS to
>remember the
>previous string, and therefore no need to keep any state regarding the previous
>attempt.
>The subsequent INVITE can really be a new INVITE., i.e. a new Call-Id.
>
>If, on the other hand, the sending UA only sends additional digits, then the
>original digits
>will have to be remembered by the UAS, and the INVITE matched up with this
>state
>so
>this INVITE must be on the same Call-Id.
>
>This latter case is similar to the way existing telephony protocols transmit
>addtional digits
>when doing overlap sending.
>
>So, upon receiving a response of 484 Address Incomplete, does the sending UA
>send
>original digits plus aditional digits on a new Call-Id or additional digits
>only
>on the same
>Call-Id with an incremented Cseq.
>
>Regards,
>
>K. Robinson.
>
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip




_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 05:43:50 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29182
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 05:43:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0A54B4433F; Mon,  8 Jan 2001 04:44:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id D9C974433C
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 04:43:57 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f08AhgG19971;
	Mon, 8 Jan 2001 11:43:42 +0100 (MET)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.40])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA16708;
	Mon, 8 Jan 2001 12:43:41 +0200 (EET)
Message-ID: <3A5999D8.44864D13@lmf.ericsson.se>
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Cc: Keith Robinson <Keith.Robinson@marconi.com>, Steve Levy <stlevy@cisco.com>
Subject: Re: [SIP] Overlap Sending
References: <802569CE.00385A56.00@marconicomms.com>
Content-Type: multipart/mixed;
 boundary="------------AF62DEB9F077BC90A480415F"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 08 Jan 2001 12:43:36 +0200

This is a multi-part message in MIME format.
--------------AF62DEB9F077BC90A480415F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

I think sending re-INVITES containing only subsequent digits will create
some problems. It's not enough that the UAS remembers the previous
INVITEs for the specific Call-ID, you may also have intermediate
redirect- and/or proxy servers that make their redirect/forwarding
decissions based on the destination number, and then they would also
have to remember the previous INVITEs, and they would possible also have
to be able to know if, and in some cases, how many digits will follow
(e.g. 4@uas.com may be routed to a complete destination than
441@uas.com, etc.) Maybe we should implement some kind of digit-map
header, or something... :)

Regards,

Christer Holmberg
Ericsson Finland



Keith Robinson wrote:
> 
> Yes, this is the type of case I have in mind. The question I have is what are
> the subsequent INVITES; are they
> 
> a) New INVITES, on a new Call-Id containing the original digits (from original
> INVITE) + subsequent digits ?
> 
> or
> 
> b) re-INVITES containing only subsequent digits ?
> 
> or
> 
> c) re-INVITES containing original digits + subsequent digits ?
> 
> The sending UAs I referred to in my previous note are those that sit in PSTN/SIP
> gateways,
> not necessarily an originating UA sitting on someones desktop.
> 
> So, the question applies as much to these interworking UAs for constructing
> the subsequent INVITEs as well as to receiving UAs for interpreting them.
> 
> Regards,
> 
> K. Robinson.
> 
> Steve Levy <stlevy@cisco.com> on 05/01/2001 22:32:00
> 
> 
> 
> 
> 
> 
> 
>  To:      Keith Robinson/MAIN/MC1@MCMAIN,
>           sip@lists.bell-labs.com
> 
>  cc:
> 
> 
> 
>  Subject: Re: [SIP] Overlap Sending
> 
> 
> Hi Keith,
> 
> I was wondering if in considering overlap sending issues and SIP if you were
> considering the case of overlap sending across multiple networks with variable
> length digits.
> 
> In this case, in order to avoid post dial delay, the digits need to be passed
> through the networks to the final destiantion network prior to end of dial
> (since the destination network is the only network that knows how many digits
> are required). So in effect there may be additional digits sent after an INVITE
> has been received and sent downstream to the callee.
> 
> Thanks,
> Steve
> 
> At 03:50 PM 1/5/01 +0000, Keith Robinson wrote:
> >
> >
> >I have the following query regarding overlap sending as defined in
> >rfc2543bis-02:
> >
> >Section 4.2.1 states the following:
> >
> >"...the UAS compares the Request-URI with Request-URI of the previous INVITE
> >request
> >for the same Call-Id. If the Request-URI  contains additional digits in the
> >'user' part, the UAS
> >treats the INVITE as adding additional digits to the original dialed string."
> >
> >This appears to imply that the subsequent INVITE contains the original dialled
> >string plus the
> >additional digits; if this is the case, then there is no need for the UAS to
> >remember the
> >previous string, and therefore no need to keep any state regarding the previous
> >attempt.
> >The subsequent INVITE can really be a new INVITE., i.e. a new Call-Id.
> >
> >If, on the other hand, the sending UA only sends additional digits, then the
> >original digits
> >will have to be remembered by the UAS, and the INVITE matched up with this
> >state
> >so
> >this INVITE must be on the same Call-Id.
> >
> >This latter case is similar to the way existing telephony protocols transmit
> >addtional digits
> >when doing overlap sending.
> >
> >So, upon receiving a response of 484 Address Incomplete, does the sending UA
> >send
> >original digits plus aditional digits on a new Call-Id or additional digits
> >only
> >on the same
> >Call-Id with an incremented Cseq.
> >
> >Regards,
> >
> >K. Robinson.
> >
> >
> >
> >
> >_______________________________________________
> >SIP mailing list
> >SIP@lists.bell-labs.com
> >http://lists.bell-labs.com/mailman/listinfo/sip
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
--------------AF62DEB9F077BC90A480415F
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------AF62DEB9F077BC90A480415F--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 06:08:50 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29315
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 06:08:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 638154433F; Mon,  8 Jan 2001 05:09:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id 4DF4444339
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 05:08:05 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 8 Jan 2001 11:07:54 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id LAA05498; Mon, 8 Jan 2001 11:06:35 GMT
Message-ID: <3A599F3C.16FBCE86@ubiquity.net>
From: Neil Deason <ndeason@ubiquity.net>
Organization: Ubiquity Software Corporation Limited
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jo Hornsby <jhornsby@ubiquity.net>
Cc: Paul Francis <paul@francis.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] question on received tag in via 
 header,draft-ietf-sip-rfc2543bis-02.txt
References: <000d01c0795a$880d1470$4e34c3c1@ubiquity.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 08 Jan 2001 11:06:36 +0000
Content-Transfer-Encoding: 7bit

Jo Hornsby wrote:
> 
> > Why is it that the receiver tag in the via header indicate the received
> > network address but not also the received port (in section 6.47.2
> > Receiver-tagged Via Header Fields)?
> 
> In a nutshell: the port is generally not considered useful since
> just because a client sends from a particular port, it doesn't
> mean that it's also listening on that port.
> 
> (I vote that this becomes a FAQ.)

I would further ask that we simply the SIP spec in this area. 
6.47.1 Requests (p.77) and 6.47.2 Receiver-tagged Via Header 
Fields (p.78) both contain text about adding the received 
parameter. In 6.47.2 this crops up in relation to NATs. As the 
received param alone will not solve NAT issues can this 
reference be removed and these two sections consolidated into 
one?

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 06:59:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29627
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 06:59:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 014A844342; Mon,  8 Jan 2001 06:00:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61])
	by lists.bell-labs.com (Postfix) with ESMTP id 062584433D
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 05:59:50 -0500 (EST)
Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc363f43d50faaf4902@cvis29.marconicomms.com>;
 Mon, 8 Jan 2001 11:59:35 +0000
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-30) id LAA08819; Mon, 8 Jan 2001 11:59:33 GMT
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 802569CE.0041D752 ; Mon, 8 Jan 2001 11:59:09 +0000
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Keith Robinson" <Keith.Robinson@marconi.com>
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
Cc: sip@lists.bell-labs.com, Steve Levy <stlevy@cisco.com>
Message-ID: <802569CE.0041D647.00@marconicomms.com>
Subject: Re: [SIP] Overlap Sending
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=VKZLrqjPrmOmSvEChoUBbhwFYQdKuMHk9uWy6Z7CRy5kNKPOKQQV5wwd"
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 11:59:15 +0000

--0__=VKZLrqjPrmOmSvEChoUBbhwFYQdKuMHk9uWy6Z7CRy5kNKPOKQQV5wwd
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



If a proxy, not serving uas.com, receives an INVITE with a R-URI of 4@uas.com,
why
would it route it differently (Route headers not withstanding) from an INVITE
with a R-URI of 441@uas.com ?
Surely, if the proxy does not serve the domain identified in the R-URI it cannot
make any
routing decisions based on the user part of the R-URI.

If, on the other hand, the proxy does serve uas.com, then it will be involved in
routing the call using the dialled
digit string and I would expect it to know such things as minimum digits to
translation and perhaps even
maximum number of digits to follow. Also, because the proxy is doing digit based
routing it must be subject to the
requirements of overlap sending so I would expect it to be stateful, at least
until call setup is complete, in which
case remembering previous call information would be reasonable. In fact, such a
proxy appears much like the
interworking UAs I referred to previously and to which my question applies.


Regards,

K. Robinson









Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:      sip@lists.bell-labs.com                             
                                                              
 cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy          
          <stlevy@cisco.com>                                  
                                                              
                                                              
                                                              
 Subject: Re: [SIP] Overlap Sending                           
                                                              








Hi,

I think sending re-INVITES containing only subsequent digits will create
some problems. It's not enough that the UAS remembers the previous
INVITEs for the specific Call-ID, you may also have intermediate
redirect- and/or proxy servers that make their redirect/forwarding
decissions based on the destination number, and then they would also
have to remember the previous INVITEs, and they would possible also have
to be able to know if, and in some cases, how many digits will follow
(e.g. 4@uas.com may be routed to a complete destination than
441@uas.com, etc.) Maybe we should implement some kind of digit-map
header, or something... :)

Regards,

Christer Holmberg
Ericsson Finland

Keith Robinson wrote:
>
> Yes, this is the type of case I have in mind. The question I have is what are
> the subsequent INVITES; are they
>
> a) New INVITES, on a new Call-Id containing the original digits (from original
> INVITE) + subsequent digits ?
>
> or
>
> b) re-INVITES containing only subsequent digits ?
>
> or
>
> c) re-INVITES containing original digits + subsequent digits ?
>
> The sending UAs I referred to in my previous note are those that sit in
PSTN/SIP
> gateways,
> not necessarily an originating UA sitting on someones desktop.
>
> So, the question applies as much to these interworking UAs for constructing
> the subsequent INVITEs as well as to receiving UAs for interpreting them.
>
> Regards,
>
> K. Robinson.
>
> Steve Levy <stlevy@cisco.com> on 05/01/2001 22:32:00
>
>
>
>
>
>
>
>  To:      Keith Robinson/MAIN/MC1@MCMAIN,
>           sip@lists.bell-labs.com
>
>  cc:
>
>
>
>  Subject: Re: [SIP] Overlap Sending
>
>
> Hi Keith,
>
> I was wondering if in considering overlap sending issues and SIP if you were
> considering the case of overlap sending across multiple networks with variable
> length digits.
>
> In this case, in order to avoid post dial delay, the digits need to be passed
> through the networks to the final destiantion network prior to end of dial
> (since the destination network is the only network that knows how many digits
> are required). So in effect there may be additional digits sent after an
INVITE
> has been received and sent downstream to the callee.
>
> Thanks,
> Steve
>
> At 03:50 PM 1/5/01 +0000, Keith Robinson wrote:
> >
> >
> >I have the following query regarding overlap sending as defined in
> >rfc2543bis-02:
> >
> >Section 4.2.1 states the following:
> >
> >"...the UAS compares the Request-URI with Request-URI of the previous INVITE
> >request
> >for the same Call-Id. If the Request-URI  contains additional digits in the
> >'user' part, the UAS
> >treats the INVITE as adding additional digits to the original dialed string."
> >
> >This appears to imply that the subsequent INVITE contains the original
dialled
> >string plus the
> >additional digits; if this is the case, then there is no need for the UAS to
> >remember the
> >previous string, and therefore no need to keep any state regarding the
previous
> >attempt.
> >The subsequent INVITE can really be a new INVITE., i.e. a new Call-Id.
> >
> >If, on the other hand, the sending UA only sends additional digits, then the
> >original digits
> >will have to be remembered by the UAS, and the INVITE matched up with this
> >state
> >so
> >this INVITE must be on the same Call-Id.
> >
> >This latter case is similar to the way existing telephony protocols transmit
> >addtional digits
> >when doing overlap sending.
> >
> >So, upon receiving a response of 484 Address Incomplete, does the sending UA
> >send
> >original digits plus aditional digits on a new Call-Id or additional digits
> >only
> >on the same
> >Call-Id with an incremented Cseq.
> >
> >Regards,
> >
> >K. Robinson.
> >
> >
> >
> >
> >_______________________________________________
> >SIP mailing list
> >SIP@lists.bell-labs.com
> >http://lists.bell-labs.com/mailman/listinfo/sip
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

--0__=VKZLrqjPrmOmSvEChoUBbhwFYQdKuMHk9uWy6Z7CRy5kNKPOKQQV5wwd
Content-type: application/octet-stream; 
	name="christer.holmberg.vcf"
Content-Disposition: attachment; filename="christer.holmberg.vcf"
Content-Transfer-Encoding: base64

YmVnaW46dmNhcmQgDQpuOkhvbG1iZXJnO0NocmlzdGVyDQp0ZWw7Y2VsbDorMzU4LTQwLTU2MDQ0
MTINCnRlbDt3b3JrOiszNTgtOS0yOTkyOTQzDQp4LW1vemlsbGEtaHRtbDpGQUxTRQ0Kb3JnOkVy
aWNzc29uO0lQIE11bHRpbWVkaWEgLyBBZHZhbmNlZCBTaWduYWxsaW5nIFJlc2VhcmNoIExhYm9y
YXRvcnkNCmFkcjo7Ozs7OzsNCnZlcnNpb246Mi4xDQplbWFpbDtpbnRlcm5ldDpjaHJpc3Rlci5o
b2xtYmVyZ0BsbWYuZXJpY3Nzb24uc2UNCnRpdGxlOlN5c3RlbSBEZXNpZ25lcg0KZm46Q2hyaXN0
ZXIgSG9sbWJlcmcNCmVuZDp2Y2FyZA0KDQo=

--0__=VKZLrqjPrmOmSvEChoUBbhwFYQdKuMHk9uWy6Z7CRy5kNKPOKQQV5wwd--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 08:15:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02046
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 08:15:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5BE5E44351; Mon,  8 Jan 2001 07:16:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id C238644342
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 07:15:11 -0500 (EST)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA07560
	for <sip@lists.bell-labs.com>; Mon, 8 Jan 2001 05:15:07 -0800 (PST)
Received: from sony-laptop (dhcp-64-102-95-107.cisco.com [64.102.95.107])
	by imop.cisco.com (Mirapoint)
	with SMTP id AAG46956;
	Mon, 8 Jan 2001 05:14:53 -0800 (PST)
Message-Id: <4.1.20010108081015.00ac9f00@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
To: sip@lists.bell-labs.com
From: Rohan Mahy <rohan@cisco.com>
Subject: Re: [SIP] REFER open issues
In-Reply-To: <4.1.20001215092137.00c80100@imop.cisco.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_4612918==_.ALT"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 08 Jan 2001 08:20:26 -0800

--=====================_4612918==_.ALT
Content-Type: text/plain; charset="us-ascii"

Hi,

I've heard some mixed interest at the IETF, and no objections to an interim
meeting to build some consensus around REFER open issues.  If you are intersted
in attending a meeting **and have posted to the list on one of these
REFER-related topics**, please indicate your availability and ability to travel
to some sample US destinations the last week of January/first week of February
by filling in the grid below.  an [x] means you are available, a [?] is a
maybe.

Of course all the meeting minutes, proposals, etc will get posted back to this
list.
Again, please do not spam the whole list with your availability.  I'll post a
summary.

        Please use a fixed-width font such as Courier.

        Available    San Jose   Dallas   New York  RaleighNC  Other

Jan 29    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
    30    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
    31    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
Feb  1    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
     2    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]

     5    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
     6    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
     7    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
     8    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
     9    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]


thanks,
-rohan


At 10:08 AM 12/15/00 , Rohan Mahy wrote:
>Hi,
>
>I'd like to summarize ALL the open issues that we have with REFER.  In the
>interest of coming to consensus, I'd like to invite interested implementers
>who have comments to meet in person before Minneapolis to close REFER open
>issues.  If folks think this is a good idea, we would certainly post the
>minutes and partial consensus back to the list for comments/changes.  As a
>strawman, I will suggest sometime in the last week of January.  A few
>plausible locations are: Dallas, New York, San Jose...  I volunteer to
>organize this if necessary.
>
>A short summary of the issues are below in no particular order:
>
>1) Retransmission problem:
>Robert Sparks already summarized this problem in his recent post.
>(a) REFER completes early, use explicit SUBSCRIBE for more info
>(b) REFER completes early and implicitly SUBSCRIBEs to more info
>(c) REFER completes after 16 secs and provides URL for SUBSCRIBE
>(d) send new REFER (new CSeq same call ID) after 32 seconds.
>
>2) Cancellation:
>If REFER returns a final response before a long INVITE transaction
>completes, how do you cancel that INVITE?  
>(a) send same REFER with ;method=CANCEL
>(b) send REFERCANCEL method
>
>3) Call-leg matching:
>Should you include call-id's in Refer-to URLs?  If not, what do you use for
>matching (Replaces or similar)?
>(a) match call-ids
>(b) use a Replaces header
>(c) use the mesh-id to setup mesh, then say BYE
>(d) use a new header
>
>4) If we choose Replaces or the like, how do we express that we want to
>*join* 2 legs via REFER?
>(a) Join header
>(b) Associate header
>(c) new method
>(d) something else
>
>5) If Refer-To contains parameters (method, transport), or potentially
>contradictory headers, what do we do with them?
>(a) allow all of them if authorized
>(b) allow a subset of methods/headers
>(c) send an error mesage
>(d) ignore the headers/parameters
>(e) ignore the whole message
>
>6) If we don't allow  ;method=BYE, how do we solve the problem described in
>the Music on 
>Hold flow?
>(a) method=BYE
>(b) ???
>
>7) How do we ask devices to do stuff for us?  [probably defer this issue]
>(a) REFER with parameters/headers
>(b) PHONECTL
>(c) some NEWMETHOD
>(d) Mbus
>(e) other
>
>Any other REFER open issues I missed?
>
>thanks,
>-rohan
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip

--=====================_4612918==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Hi,<br>
<br>
I've heard some mixed interest at the IETF, and no objections to an
interim meeting to build some consensus around REFER open issues.&nbsp;
If you are intersted in attending a meeting **and have posted to the list
on one of these REFER-related topics**, please indicate your availability
and ability to travel to some sample US destinations the last week of
January/first week of February by filling in the grid below.&nbsp; an [x]
means you are available, a [?] is a maybe.<br>
<br>
Of course all the meeting minutes, proposals, etc will get posted back to
this list.<br>
Again, please do not spam the whole list with your availability.&nbsp;
I'll post a summary.<br>
<br>
<font face="Courier, Courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Please use a fixed-width font such as Courier.<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Available&nbsp;&nbsp;&nbsp;
San Jose&nbsp;&nbsp; Dallas&nbsp;&nbsp; New York&nbsp; RaleighNC&nbsp;
Other<br>
<br>
Jan 29&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; 30&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; 31&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>
Feb&nbsp; 1&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; 2&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>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; 5&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; 6&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; 7&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; 8&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; 9&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>
<br>
<br>
</font>thanks,<br>
-rohan<br>
<br>
<br>
At 10:08 AM 12/15/00 , Rohan Mahy wrote:<br>
&gt;Hi,<br>
&gt;<br>
&gt;I'd like to summarize ALL the open issues that we have with
REFER.&nbsp; In the<br>
&gt;interest of coming to consensus, I'd like to invite interested
implementers<br>
&gt;who have comments to meet in person before Minneapolis to close REFER
open<br>
&gt;issues.&nbsp; If folks think this is a good idea, we would certainly
post the<br>
&gt;minutes and partial consensus back to the list for
comments/changes.&nbsp; As a<br>
&gt;strawman, I will suggest sometime in the last week of January.&nbsp;
A few<br>
&gt;plausible locations are: Dallas, New York, San Jose...&nbsp; I
volunteer to<br>
&gt;organize this if necessary.<br>
&gt;<br>
&gt;A short summary of the issues are below in no particular order:<br>
&gt;<br>
&gt;1) Retransmission problem:<br>
&gt;Robert Sparks already summarized this problem in his recent
post.<br>
&gt;(a) REFER completes early, use explicit SUBSCRIBE for more info<br>
&gt;(b) REFER completes early and implicitly SUBSCRIBEs to more 
info<br>
&gt;(c) REFER completes after 16 secs and provides URL for 
SUBSCRIBE<br>
&gt;(d) send new REFER (new CSeq same call ID) after 32 seconds.<br>
&gt;<br>
&gt;2) Cancellation:<br>
&gt;If REFER returns a final response before a long INVITE
transaction<br>
&gt;completes, how do you cancel that INVITE?&nbsp; <br>
&gt;(a) send same REFER with ;method=CANCEL<br>
&gt;(b) send REFERCANCEL method<br>
&gt;<br>
&gt;3) Call-leg matching:<br>
&gt;Should you include call-id's in Refer-to URLs?&nbsp; If not, what do
you use for<br>
&gt;matching (Replaces or similar)?<br>
&gt;(a) match call-ids<br>
&gt;(b) use a Replaces header<br>
&gt;(c) use the mesh-id to setup mesh, then say BYE<br>
&gt;(d) use a new header<br>
&gt;<br>
&gt;4) If we choose Replaces or the like, how do we express that we want
to<br>
&gt;*join* 2 legs via REFER?<br>
&gt;(a) Join header<br>
&gt;(b) Associate header<br>
&gt;(c) new method<br>
&gt;(d) something else<br>
&gt;<br>
&gt;5) If Refer-To contains parameters (method, transport), or
potentially<br>
&gt;contradictory headers, what do we do with them?<br>
&gt;(a) allow all of them if authorized<br>
&gt;(b) allow a subset of methods/headers<br>
&gt;(c) send an error mesage<br>
&gt;(d) ignore the headers/parameters<br>
&gt;(e) ignore the whole message<br>
&gt;<br>
&gt;6) If we don't allow&nbsp; ;method=BYE, how do we solve the problem
described in<br>
&gt;the Music on <br>
&gt;Hold flow?<br>
&gt;(a) method=BYE<br>
&gt;(b) ???<br>
&gt;<br>
&gt;7) How do we ask devices to do stuff for us?&nbsp; [probably defer
this issue]<br>
&gt;(a) REFER with parameters/headers<br>
&gt;(b) PHONECTL<br>
&gt;(c) some NEWMETHOD<br>
&gt;(d) Mbus<br>
&gt;(e) other<br>
&gt;<br>
&gt;Any other REFER open issues I missed?<br>
&gt;<br>
&gt;thanks,<br>
&gt;-rohan<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;_______________________________________________<br>
&gt;SIP mailing list<br>
&gt;SIP@lists.bell-labs.com<br>
&gt;<a href="http://lists.bell-labs.com/mailman/listinfo/sip" eudora="autourl">http://lists.bell-labs.com/mailman/listinfo/sip</a><br>
</html>

--=====================_4612918==_.ALT--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 08:41:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02870
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 08:41:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 85C1744338; Mon,  8 Jan 2001 07:42:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id E895844336
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 07:41:14 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f08DesG14376;
	Mon, 8 Jan 2001 14:40:55 +0100 (MET)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.40])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA27236;
	Mon, 8 Jan 2001 15:40:49 +0200 (EET)
Message-ID: <3A59C35F.2C6B1251@lmf.ericsson.se>
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Cc: Keith Robinson <Keith.Robinson@marconi.com>, Steve Levy <stlevy@cisco.com>
Subject: Re: [SIP] Overlap Sending
References: <802569CE.0041D647.00@marconicomms.com>
Content-Type: multipart/mixed;
 boundary="------------E026EF5EF9A5797FCF83FAA9"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 08 Jan 2001 15:40:47 +0200

This is a multi-part message in MIME format.
--------------E026EF5EF9A5797FCF83FAA9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi,

>If a proxy, not serving uas.com, receives an INVITE with a R-URI of 4@uas.com,
>why would it route it differently (Route headers not withstanding) from an INVITE
>with a R-URI of 441@uas.com ?

I don't know. I haven't seen a proxy that would route depending on the
user, but it COULD happend. Let's assume , for example, that you do a
SRV DNS lookup, and get a list of servers. Then you MAY choose a
different server, for load balance purpose e.g., depending on the user
name. Just an example...

And, what happen if you use a TEL-URL, where you have to route depending
on the user name (=telephone number). I guess using a ENUM DNS lookup
COULD route it to the same host, but then I guess you would have to
configure your DNS to for all the possible combinations (4.e164.arpa,
44.e164.arpa and 441.e164.arpa)...

>Surely, if the proxy does not serve the domain identified in the R-URI it cannot
>make any routing decisions based on the user part of the R-URI. 
>If, on the other hand, the proxy does serve uas.com, then it will be involved in
>routing the call using the dialled digit string and I would expect it to know such things as minimum digits to
>translation and perhaps even maximum number of digits to follow. Also, because the proxy is doing digit based
>routing it must be subject to the requirements of overlap sending so I would expect it to be stateful, at >least until call setup is complete, in which case remembering previous call information would be reasonable. >In fact, such a proxy appears much like the interworking UAs I referred to previously and to which my question >applies.

That was my point - that you also have to have support for this in your
proxies, and not only in your client.

I think the issue is that there are lots of what-ifs involved in this,
and it should be specified how the specific cases are handled -
especially by proxies and redirect servers.

Regards,

Christer Holmberg
Ericsson Finland

 



> Regards,
> 
> K. Robinson
> 
> Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
> 
> 
> 
> 
> 
> 
> 

Keith Robinson wrote:
> 
> If a proxy, not serving uas.com, receives an INVITE with a R-URI of 4@uas.com,
> why
> would it route it differently (Route headers not withstanding) from an INVITE
> with a R-URI of 441@uas.com ?
> Surely, if the proxy does not serve the domain identified in the R-URI it cannot
> make any
> routing decisions based on the user part of the R-URI.
> 
> If, on the other hand, the proxy does serve uas.com, then it will be involved in
> routing the call using the dialled
> digit string and I would expect it to know such things as minimum digits to
> translation and perhaps even
> maximum number of digits to follow. Also, because the proxy is doing digit based
> routing it must be subject to the
> requirements of overlap sending so I would expect it to be stateful, at least
> until call setup is complete, in which
> case remembering previous call information would be reasonable. In fact, such a
> proxy appears much like the
> interworking UAs I referred to previously and to which my question applies.
> 
> Regards,
> 
> K. Robinson
> 
> Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
> 
> 
> 
> 
> 
> 
> 
>  To:      sip@lists.bell-labs.com
> 
>  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
>           <stlevy@cisco.com>
> 
> 
> 
>  Subject: Re: [SIP] Overlap Sending
> 
> 
> Hi,
> 
> I think sending re-INVITES containing only subsequent digits will create
> some problems. It's not enough that the UAS remembers the previous
> INVITEs for the specific Call-ID, you may also have intermediate
> redirect- and/or proxy servers that make their redirect/forwarding
> decissions based on the destination number, and then they would also
> have to remember the previous INVITEs, and they would possible also have
> to be able to know if, and in some cases, how many digits will follow
> (e.g. 4@uas.com may be routed to a complete destination than
> 441@uas.com, etc.) Maybe we should implement some kind of digit-map
> header, or something... :)
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> Keith Robinson wrote:
> >
> > Yes, this is the type of case I have in mind. The question I have is what are
> > the subsequent INVITES; are they
> >
> > a) New INVITES, on a new Call-Id containing the original digits (from original
> > INVITE) + subsequent digits ?
> >
> > or
> >
> > b) re-INVITES containing only subsequent digits ?
> >
> > or
> >
> > c) re-INVITES containing original digits + subsequent digits ?
> >
> > The sending UAs I referred to in my previous note are those that sit in
> PSTN/SIP
> > gateways,
> > not necessarily an originating UA sitting on someones desktop.
> >
> > So, the question applies as much to these interworking UAs for constructing
> > the subsequent INVITEs as well as to receiving UAs for interpreting them.
> >
> > Regards,
> >
> > K. Robinson.
> >
> > Steve Levy <stlevy@cisco.com> on 05/01/2001 22:32:00
> >
> >
> >
> >
> >
> >
> >
> >  To:      Keith Robinson/MAIN/MC1@MCMAIN,
> >           sip@lists.bell-labs.com
> >
> >  cc:
> >
> >
> >
> >  Subject: Re: [SIP] Overlap Sending
> >
> >
> > Hi Keith,
> >
> > I was wondering if in considering overlap sending issues and SIP if you were
> > considering the case of overlap sending across multiple networks with variable
> > length digits.
> >
> > In this case, in order to avoid post dial delay, the digits need to be passed
> > through the networks to the final destiantion network prior to end of dial
> > (since the destination network is the only network that knows how many digits
> > are required). So in effect there may be additional digits sent after an
> INVITE
> > has been received and sent downstream to the callee.
> >
> > Thanks,
> > Steve
> >
> > At 03:50 PM 1/5/01 +0000, Keith Robinson wrote:
> > >
> > >
> > >I have the following query regarding overlap sending as defined in
> > >rfc2543bis-02:
> > >
> > >Section 4.2.1 states the following:
> > >
> > >"...the UAS compares the Request-URI with Request-URI of the previous INVITE
> > >request
> > >for the same Call-Id. If the Request-URI  contains additional digits in the
> > >'user' part, the UAS
> > >treats the INVITE as adding additional digits to the original dialed string."
> > >
> > >This appears to imply that the subsequent INVITE contains the original
> dialled
> > >string plus the
> > >additional digits; if this is the case, then there is no need for the UAS to
> > >remember the
> > >previous string, and therefore no need to keep any state regarding the
> previous
> > >attempt.
> > >The subsequent INVITE can really be a new INVITE., i.e. a new Call-Id.
> > >
> > >If, on the other hand, the sending UA only sends additional digits, then the
> > >original digits
> > >will have to be remembered by the UAS, and the INVITE matched up with this
> > >state
> > >so
> > >this INVITE must be on the same Call-Id.
> > >
> > >This latter case is similar to the way existing telephony protocols transmit
> > >addtional digits
> > >when doing overlap sending.
> > >
> > >So, upon receiving a response of 484 Address Incomplete, does the sending UA
> > >send
> > >original digits plus aditional digits on a new Call-Id or additional digits
> > >only
> > >on the same
> > >Call-Id with an incremented Cseq.
> > >
> > >Regards,
> > >
> > >K. Robinson.
> > >
> > >
> > >
> > >
> > >_______________________________________________
> > >SIP mailing list
> > >SIP@lists.bell-labs.com
> > >http://lists.bell-labs.com/mailman/listinfo/sip
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
--------------E026EF5EF9A5797FCF83FAA9
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------E026EF5EF9A5797FCF83FAA9--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 09:31:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04927
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 09:31:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CD92B44337; Mon,  8 Jan 2001 08:32:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 32B6444336
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 08:31:59 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA29805;
	Mon, 8 Jan 2001 09:31:40 -0500 (EST)
Message-ID: <3A59CF4C.21F42471@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Nishith Chudasama <nishith76@usa.net>
Cc: sip@lists.bell-labs.com, vijethd@rediffmail.com
Subject: Re: [SIP] DNS Lookup
References: <20010108100912.2235.qmail@www0q.netaddress.usa.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 08 Jan 2001 09:31:40 -0500
Content-Transfer-Encoding: 7bit

Nishith Chudasama wrote:
> 
> Hi all,
> 
> Can anybody let me know if there is some readymade piece of code available on
> the net for DNS queries for SIP clients/Servers.
> 
> If not, can anybody point to the document specifying the procedure for doing
> this?

http://www.cs.columbia.edu/sip/implementations.html has a link to an
SRV-enhanced resparse implementation.


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 09:56:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06066
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 09:56:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2542B4433D; Mon,  8 Jan 2001 08:57:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 01E4144336
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 08:56:37 -0500 (EST)
Received: from CINQUECENTO ([63.110.3.212])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id JAA05094;
	Mon, 8 Jan 2001 09:58:26 -0500 (EST)
From: "Robert Sparks" <rsparks@dynamicsoft.com>
To: "'Sean Olson'" <sean.olson@ericsson.com>,
        "Henning Schulzrinne" <hgs@cs.columbia.edu>
Cc: "Jeff Mark" <Jeff.Mark@dialogic.com>,
        "'Vijeth D'" <vijethd@rediffmail.com>, <sip@lists.bell-labs.com>
Subject: RE: [SIP] Also field
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3047488@DYN-TX-EXCH-001.dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <3A564347.7080509@ericsson.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 08:52:42 -0600
Content-Transfer-Encoding: 7bit

This doesn't extend to many non-sip URLs.

> -----Original Message-----
> From: Sean Olson [mailto:sean.olson@ericsson.com]
> Sent: Friday, January 05, 2001 3:57 PM
> To: Henning Schulzrinne
> Cc: Jeff Mark; 'Vijeth D'; sip@lists.bell-labs.com
> Subject: Re: [SIP] Also field
> 
> 
> 
> 
> Henning Schulzrinne wrote:
> 
> > 
> > To muddy the water a bit more with an unrelated topic, I 
> wonder if some
> > of the ugliness of encoding methods and headers in the Refer-To URL
> > could be avoided by also attaching the message to be generated as a
> > message/sip body.
> > 
> > Henning
> 
> I second that idea -- at least as an option in the absence of 
> a Refer-To 
> URL.
> It also opens the door for nice things like S/MIME.
> /sean
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 10:03:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06371
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 10:03:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9D3DF4433D; Mon,  8 Jan 2001 09:04:02 -0500 (EST)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id E867244337
	for <sip@share.research.bell-labs.com>; Mon,  8 Jan 2001 09:03:29 -0500 (EST)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Jan  8 10:01:51 EST 2001
Received: by lists.bell-labs.com (Postfix)
	id E12B044384; Mon,  8 Jan 2001 09:49:57 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5])
	by lists.bell-labs.com (Postfix) with SMTP id 9550A4437D
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 09:49:57 -0500 (EST)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id IAA29254; Mon, 8 Jan 2001 08:49:55 -0600
Cc: sip@lists.bell-labs.com
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id IAA29235; Mon, 8 Jan 2001 08:49:54 -0600
Message-ID: <3A59D380.D7B57426@lucent.com>
From: Vijay Gurbani <vkg@lucent.com>
Organization: Lucent Technologies/Bell Laboratories
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Nishith Chudasama <nishith76@usa.net>
Original-CC: sip@lists.bell-labs.com
Subject: Re: [SIP] REGISTRAR functions.
References: <20010108095051.8837.qmail@nwcst276.netaddress.usa.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 08 Jan 2001 08:49:36 -0600
Content-Transfer-Encoding: 7bit

Nishith Chudasama wrote:
> 
> Following are the queries regarding SIP REGISTRAR implementation. Kindly 
> let me know if anybody has the solution.....
> 
> 1. Where can I get the specifications to develop a SIP Registrar?

RFC 2453 (and subsequent bis modifications)

> 2. For a particular USER registration, what all information from the 
> REGISTER request should be stored by Registrar?(Till the registration 
> expires...)

Presumably, at least the Contact and Expire information.  If the REGISTER 
request had a CPL (or any other) payload, that'll need to be stored as well.
 
> 3. If the REGISTRAR and Location server are not co-located, How and what 
> to inform the Location server following a REGISTER request from a User?

Implementation dependent.
 
> 4. What are the messages exchanged between a SIP proxy/Redirect server and 
> a Location server/Registrar?

If they are co-located, a functional API would suffice.  If not, SIP itself
could be a candidate.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 10:49:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08344
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 10:49:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 99AB74433F; Mon,  8 Jan 2001 09:50:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from muninn.ctccom.net (muninn.ctccom.net [63.209.246.44])
	by lists.bell-labs.com (Postfix) with ESMTP id AB81244337
	for <SIP@lists.bell-labs.com>; Mon,  8 Jan 2001 09:49:29 -0500 (EST)
Received: from MBRAHMANAPALLY ([64.69.125.177])
	by muninn.ctccom.net (Mirapoint)
	with SMTP id ABQ20976;
	Mon, 8 Jan 2001 10:49:02 -0500 (EST)
From: "Madhubabu Brahmanapally" <madhubabu@kenetec.com>
To: <SIP@lists.bell-labs.com>
Message-ID: <002601c0798a$be5f53a0$c500a8c0@MBRAHMANAPALLY>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Subject: [SIP] Small Query.
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 10:50:36 -0500
Content-Transfer-Encoding: 7bit

Hi list,henry,rosenberg,

Iam new to SIP. Can any one help me finding (whitepapers,presenatations
,etc..) the differences between SIP and MGCP or H.248. As its not clear why
SIP cannot be used between MG and MGC. SIP appears to have the similar
client-server relationship except for the  additional addressing capability?

Madhu


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 10:59:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08676
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 10:59:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 73E5C44349; Mon,  8 Jan 2001 10:00:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id F117F4433F
	for <SIP@lists.bell-labs.com>; Mon,  8 Jan 2001 09:59:23 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 8 Jan 2001 15:59:12 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id PAA25746; Mon, 8 Jan 2001 15:57:49 GMT
Message-ID: <3A59E37D.C5440C04@ubiquity.net>
From: Neil Deason <ndeason@ubiquity.net>
Organization: Ubiquity Software Corporation Limited
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Madhubabu Brahmanapally <madhubabu@kenetec.com>
Cc: SIP@lists.bell-labs.com
Subject: Re: [SIP] Small Query.
References: <002601c0798a$be5f53a0$c500a8c0@MBRAHMANAPALLY>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 08 Jan 2001 15:57:49 +0000
Content-Transfer-Encoding: 7bit

Please consult the SIP FAQ where you will find 
an answer to this question ... linked to from

http://www.cs.columbia.edu/~hgs/sip

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

Madhubabu Brahmanapally wrote:
> 
> Hi list,henry,rosenberg,
> 
> Iam new to SIP. Can any one help me finding (whitepapers,presenatations
> ,etc..) the differences between SIP and MGCP or H.248. As its not clear why
> SIP cannot be used between MG and MGC. SIP appears to have the similar
> client-server relationship except for the  additional addressing capability?
> 
> Madhu
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 11:38:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10019
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 11:38:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 69DBE4433B; Mon,  8 Jan 2001 10:39:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by lists.bell-labs.com (Postfix) with ESMTP id 4B7FB44337
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 10:38:50 -0500 (EST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Mon, 8 Jan 2001 08:37:49 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Jan 2001 08:38:34 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532);
	 Mon, 8 Jan 2001 08:38:34 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0
content-class: urn:content-classes:message
Subject: RE: [SIP] Early media replacement.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1255"
Message-ID: <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9E9@speak.dogfood>
Thread-Topic: [SIP] Early media replacement.
Thread-Index: AcB5SZA+1uXWX9HBQJiJi6rLjttDYwARb5dA
From: "Christian Huitema" <huitema@exchange.microsoft.com>
To: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>,
        "SIP List" <sip@lists.bell-labs.com>
X-OriginalArrivalTime: 08 Jan 2001 16:38:34.0447 (UTC) FILETIME=[714D15F0:01C07991]
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 08:38:35 -0800
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA10019

>> So, that old 183 draft which has expired will be revived, and 
>> in it will be 
>> the stuff for handling basic early media at the SDP/SIP level. 
>> 
>There are other problems with deprecating early media by using 
>re-INVITE. Consider the case where an INVITE request is 
>forked by a proxy to both a SIP desktop client and a PSTn gateway. 
>If the gateway immediately sends a 200 OK on receipt of an INVUITE 
>(with a one-way SDP body to relay the remote ringback) then the 
>desktop client will never get a chance to answer the call. 
>Between two PSTN gateways you will have a race condition.

Robert,

It would be nice to collect a complete list of issues, so that we can
really understand what is the rationale for the 183 extensions. Frankly,
our main objective right now should be to keep SIP simple; from an
architecture point of view, it is very desirable to use a single
mechanism for many purposes (i.e. re-INVITE) rather than invent a
specific hack for every specific problem (i.e. 183). 

Your "race condition" argument is not terribly convincing. The PSTN vs
desktop case that you describe is not different from the possible
race condition between a desktop and an answering machine, or, for
that matter, of the possible race condition between two PSTN gateways.
Forking an INVITE inherently creates a race condition: the first 
leg that responds with a 200-OK gets the call. Early media just makes
the matter more confusing. Imagine a call forked to two PSTN gateways,
one sending an early media that says "please dial 1 for an immediate
connection, dial 2 for voice mail" and another that says "this is
a protected line, please enter your PIN number." How exactly does
183 help in this case?

In fact, the billing argument is not very convincing either. If we
create a 183 response, we effectively create another way to establish
a call. So, I can program my desktop to always answer with a 183
response, a courtesy to my callers who won't be billed. Sure, the
PSTN will time out eventually, but the time out is rather long --
I will need to check, but it is at least 30 seconds, sufficient for
most "answering machine" conditions. Besides, I can still send the
200 OK if the call lasts longer than the timer...

-- Christian Huitema

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 12:01:43 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10882
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 12:01:43 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 57F8344346; Mon,  8 Jan 2001 11:01:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53])
	by lists.bell-labs.com (Postfix) with ESMTP id 1015744344
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 11:00:15 -0500 (EST)
Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc363f43550fbbe4842@cvis21.Marconicomms.com>;
 Mon, 8 Jan 2001 16:55:35 +0000
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-30) id QAA28763; Mon, 8 Jan 2001 16:54:56 GMT
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 802569CE.005CDC16 ; Mon, 8 Jan 2001 16:54:16 +0000
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Keith Robinson" <Keith.Robinson@marconi.com>
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
Cc: sip@lists.bell-labs.com, Steve Levy <stlevy@cisco.com>
Message-ID: <802569CE.005CD879.00@marconicomms.com>
Subject: Re: [SIP] Overlap Sending
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=IEOLPQKfBUyUsJFmLRJPm9K2K8upS5ZTpdYnPQgncLqXJZx0DV81H3uo"
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 16:54:18 +0000

--0__=IEOLPQKfBUyUsJFmLRJPm9K2K8upS5ZTpdYnPQgncLqXJZx0DV81H3uo
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline





Let's consider the following point:

"I don't know. I haven't seen a proxy that would route depending on the
user, but it COULD happend. Let's assume , for example, that you do a
SRV DNS lookup, and get a list of servers. Then you MAY choose a
different server, for load balance purpose e.g., depending on the user
name. Just an example..."

One way of ensuring that subsequent requests always traverse a given SIP
node is for that node to Record-Route or supply a Contact ; it is likely that
proxies and
UAS at PSTN interworking points will require to stay in the signalling path
during
call setup so will do so.  Now, suppose one such node receives an initial INVITE
with
a R-URI of sip:654@sipgw.com and creates a Contact header thus:

Contact: sip:654@sipgw.com;maddr=sipgw.com

This is then returned in the 484 response so that the sending UA may build a
Route header from it. Here is my first concern; will the sending UA treat the
subsequent INVITE as a subsequent INVITE or as a new INVITE on a new
Call-Id ? I ask because the 484 response is non-200 final response which
implies that that call attempt has failed; obviously in this case it hasn't
failed
(not yet, anyway) its just been partially set up.  Does this lead to special
case handling
for a particular 4XX response ? In fact, the 484 is almost like an informational
response.
Would it be better to send an informational response (say 183) and the spec
updated to
allow subsequent INVITEs to be sent before the final ACK (a point raised by J.
Rosenberg
earlier on the list, but in a different context - to convey updated SDP
information).

Assuming the above is resolved one way or another, then a SIP node preceding
sipgw.com is going to receive a subsequent INVITE for this call (containing
additional
digits 321)  that will look something like:

INVITE sip:321@preceding.sipgw.com
Route: sip:654@sipgw.com;maddr=sipgw.com

As a Route header is present, this will be used to route the INVITE so
therefore sipgw.com will receive an INVITE with the following Request
Line:

INVITE sip:654@sipgw.com;maddr=sipgw.com

And here is a more worrying problem, the subsequent digits have been lost.
The situation would be no better if the subsequent INVITE contained original
digits
plus subsequent digits; they would still be lost.

The problem stems from the fact that the R-URI is supposed to be invariant at
each
node during the lifetime of the call leg, yet to do overlap sending it is being
used to
convey new information so therefore does not remain invariant and other parts of
the
protocol which assume it is invariant e.g., routing using the Route header
break.

Using a TEL URL does not help either; the digits would still be lost after the
popping of
the Route entry into the R-URI.

It would be easier to implement overlap sending if a seperate header could be
used to
convey the dialled digits, so an original INVITE may look something like:

INVITE sip:digitdecode@sipgw.com
Current-Dial-String: 01623

The subsequent INVITES would then look something like:

INVITE sip:digitdecode@sipgw.com;maddr=sipgw.com
Current-Dial-String: 01623654398

This ties in with your point of implementing a digit map header.

Regards,

K. Robinson.















Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 13:40:47
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:      sip@lists.bell-labs.com                             
                                                              
 cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy          
          <stlevy@cisco.com>                                  
                                                              
                                                              
                                                              
 Subject: Re: [SIP] Overlap Sending                           
                                                              









Hi,

>If a proxy, not serving uas.com, receives an INVITE with a R-URI of 4@uas.com,
>why would it route it differently (Route headers not withstanding) from an
INVITE
>with a R-URI of 441@uas.com ?

I don't know. I haven't seen a proxy that would route depending on the
user, but it COULD happend. Let's assume , for example, that you do a
SRV DNS lookup, and get a list of servers. Then you MAY choose a
different server, for load balance purpose e.g., depending on the user
name. Just an example...

And, what happen if you use a TEL-URL, where you have to route depending
on the user name (=telephone number). I guess using a ENUM DNS lookup
COULD route it to the same host, but then I guess you would have to
configure your DNS to for all the possible combinations (4.e164.arpa,
44.e164.arpa and 441.e164.arpa)...

>Surely, if the proxy does not serve the domain identified in the R-URI it
cannot
>make any routing decisions based on the user part of the R-URI.
>If, on the other hand, the proxy does serve uas.com, then it will be involved
in
>routing the call using the dialled digit string and I would expect it to know
such things as minimum digits to
>translation and perhaps even maximum number of digits to follow. Also, because
the proxy is doing digit based
>routing it must be subject to the requirements of overlap sending so I would
expect it to be stateful, at >least until call setup is complete, in which case
remembering previous call information would be reasonable. >In fact, such a
proxy appears much like the interworking UAs I referred to previously and to
which my question >applies.

That was my point - that you also have to have support for this in your
proxies, and not only in your client.

I think the issue is that there are lots of what-ifs involved in this,
and it should be specified how the specific cases are handled -
especially by proxies and redirect servers.

Regards,

Christer Holmberg
Ericsson Finland





> Regards,
>
> K. Robinson
>
> Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
>
>
>
>
>
>
>

Keith Robinson wrote:
>
> If a proxy, not serving uas.com, receives an INVITE with a R-URI of 4@uas.com,
> why
> would it route it differently (Route headers not withstanding) from an INVITE
> with a R-URI of 441@uas.com ?
> Surely, if the proxy does not serve the domain identified in the R-URI it
cannot
> make any
> routing decisions based on the user part of the R-URI.
>
> If, on the other hand, the proxy does serve uas.com, then it will be involved
in
> routing the call using the dialled
> digit string and I would expect it to know such things as minimum digits to
> translation and perhaps even
> maximum number of digits to follow. Also, because the proxy is doing digit
based
> routing it must be subject to the
> requirements of overlap sending so I would expect it to be stateful, at least
> until call setup is complete, in which
> case remembering previous call information would be reasonable. In fact, such
a
> proxy appears much like the
> interworking UAs I referred to previously and to which my question applies.
>
> Regards,
>
> K. Robinson
>
> Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
>
>
>
>
>
>
>
>  To:      sip@lists.bell-labs.com
>
>  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
>           <stlevy@cisco.com>
>
>
>
>  Subject: Re: [SIP] Overlap Sending
>
>
> Hi,
>
> I think sending re-INVITES containing only subsequent digits will create
> some problems. It's not enough that the UAS remembers the previous
> INVITEs for the specific Call-ID, you may also have intermediate
> redirect- and/or proxy servers that make their redirect/forwarding
> decissions based on the destination number, and then they would also
> have to remember the previous INVITEs, and they would possible also have
> to be able to know if, and in some cases, how many digits will follow
> (e.g. 4@uas.com may be routed to a complete destination than
> 441@uas.com, etc.) Maybe we should implement some kind of digit-map
> header, or something... :)
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
> Keith Robinson wrote:
> >
> > Yes, this is the type of case I have in mind. The question I have is what
are
> > the subsequent INVITES; are they
> >
> > a) New INVITES, on a new Call-Id containing the original digits (from
original
> > INVITE) + subsequent digits ?
> >
> > or
> >
> > b) re-INVITES containing only subsequent digits ?
> >
> > or
> >
> > c) re-INVITES containing original digits + subsequent digits ?
> >
> > The sending UAs I referred to in my previous note are those that sit in
> PSTN/SIP
> > gateways,
> > not necessarily an originating UA sitting on someones desktop.
> >
> > So, the question applies as much to these interworking UAs for constructing
> > the subsequent INVITEs as well as to receiving UAs for interpreting them.
> >
> > Regards,
> >
> > K. Robinson.
> >
> > Steve Levy <stlevy@cisco.com> on 05/01/2001 22:32:00
> >
> >
> >
> >
> >
> >
> >
> >  To:      Keith Robinson/MAIN/MC1@MCMAIN,
> >           sip@lists.bell-labs.com
> >
> >  cc:
> >
> >
> >
> >  Subject: Re: [SIP] Overlap Sending
> >
> >
> > Hi Keith,
> >
> > I was wondering if in considering overlap sending issues and SIP if you were
> > considering the case of overlap sending across multiple networks with
variable
> > length digits.
> >
> > In this case, in order to avoid post dial delay, the digits need to be
passed
> > through the networks to the final destiantion network prior to end of dial
> > (since the destination network is the only network that knows how many
digits
> > are required). So in effect there may be additional digits sent after an
> INVITE
> > has been received and sent downstream to the callee.
> >
> > Thanks,
> > Steve
> >
> > At 03:50 PM 1/5/01 +0000, Keith Robinson wrote:
> > >
> > >
> > >I have the following query regarding overlap sending as defined in
> > >rfc2543bis-02:
> > >
> > >Section 4.2.1 states the following:
> > >
> > >"...the UAS compares the Request-URI with Request-URI of the previous
INVITE
> > >request
> > >for the same Call-Id. If the Request-URI  contains additional digits in the
> > >'user' part, the UAS
> > >treats the INVITE as adding additional digits to the original dialed
string."
> > >
> > >This appears to imply that the subsequent INVITE contains the original
> dialled
> > >string plus the
> > >additional digits; if this is the case, then there is no need for the UAS
to
> > >remember the
> > >previous string, and therefore no need to keep any state regarding the
> previous
> > >attempt.
> > >The subsequent INVITE can really be a new INVITE., i.e. a new Call-Id.
> > >
> > >If, on the other hand, the sending UA only sends additional digits, then
the
> > >original digits
> > >will have to be remembered by the UAS, and the INVITE matched up with this
> > >state
> > >so
> > >this INVITE must be on the same Call-Id.
> > >
> > >This latter case is similar to the way existing telephony protocols
transmit
> > >addtional digits
> > >when doing overlap sending.
> > >
> > >So, upon receiving a response of 484 Address Incomplete, does the sending
UA
> > >send
> > >original digits plus aditional digits on a new Call-Id or additional digits
> > >only
> > >on the same
> > >Call-Id with an incremented Cseq.
> > >
> > >Regards,
> > >
> > >K. Robinson.
> > >
> > >
> > >
> > >
> > >_______________________________________________
> > >SIP mailing list
> > >SIP@lists.bell-labs.com
> > >http://lists.bell-labs.com/mailman/listinfo/sip
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip

--0__=IEOLPQKfBUyUsJFmLRJPm9K2K8upS5ZTpdYnPQgncLqXJZx0DV81H3uo
Content-type: application/octet-stream; 
	name="christer.holmberg.vcf"
Content-Disposition: attachment; filename="christer.holmberg.vcf"
Content-Transfer-Encoding: base64

YmVnaW46dmNhcmQgDQpuOkhvbG1iZXJnO0NocmlzdGVyDQp0ZWw7Y2VsbDorMzU4LTQwLTU2MDQ0
MTINCnRlbDt3b3JrOiszNTgtOS0yOTkyOTQzDQp4LW1vemlsbGEtaHRtbDpGQUxTRQ0Kb3JnOkVy
aWNzc29uO0lQIE11bHRpbWVkaWEgLyBBZHZhbmNlZCBTaWduYWxsaW5nIFJlc2VhcmNoIExhYm9y
YXRvcnkNCmFkcjo7Ozs7OzsNCnZlcnNpb246Mi4xDQplbWFpbDtpbnRlcm5ldDpjaHJpc3Rlci5o
b2xtYmVyZ0BsbWYuZXJpY3Nzb24uc2UNCnRpdGxlOlN5c3RlbSBEZXNpZ25lcg0KZm46Q2hyaXN0
ZXIgSG9sbWJlcmcNCmVuZDp2Y2FyZA0KDQo=

--0__=IEOLPQKfBUyUsJFmLRJPm9K2K8upS5ZTpdYnPQgncLqXJZx0DV81H3uo--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 12:11:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11306
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 12:11:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CAEA34433B; Mon,  8 Jan 2001 11:12:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by lists.bell-labs.com (Postfix) with ESMTP id 0B0F844337
	for <SIP@lists.bell-labs.com>; Mon,  8 Jan 2001 11:11:18 -0500 (EST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Mon, 8 Jan 2001 09:10:17 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Jan 2001 09:11:02 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532);
	 Mon, 8 Jan 2001 09:11:02 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0
content-class: urn:content-classes:message
Subject: RE: [SIP] Small Query.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <CC2E64D4B3BAB646A87B5A3AE97090420EFB3F3B@speak.dogfood>
Thread-Topic: [SIP] Small Query.
Thread-Index: AcB5ir8hpCSQEdgOTJGIyA7797nkBwACxuOA
From: "Christian Huitema" <huitema@exchange.microsoft.com>
To: "Madhubabu Brahmanapally" <madhubabu@kenetec.com>,
        <SIP@lists.bell-labs.com>
X-OriginalArrivalTime: 08 Jan 2001 17:11:02.0478 (UTC) FILETIME=[FA6B06E0:01C07995]
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 09:11:04 -0800
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA11306

Check: http://www.argreenhouse.com/SGCP/sgcp-faq.shtml
and    http://www.argreenhouse.com/SGCP/sgcp2sip.shtml

-- Christian Huitema

> -----Original Message-----
> From: Madhubabu Brahmanapally [mailto:madhubabu@kenetec.com]
> Sent: Monday, January 08, 2001 7:51 AM
> To: SIP@lists.bell-labs.com
> Subject: [SIP] Small Query.
> 
> 
> Hi list,henry,rosenberg,
> 
> Iam new to SIP. Can any one help me finding 
> (whitepapers,presenatations
> ,etc..) the differences between SIP and MGCP or H.248. As its 
> not clear why
> SIP cannot be used between MG and MGC. SIP appears to have the similar
> client-server relationship except for the  additional 
> addressing capability?
> 
> Madhu
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 13:17:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12855
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 13:17:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C4FBB4433A; Mon,  8 Jan 2001 12:18:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 1A80E44337
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 12:17:07 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA13228;
	Mon, 8 Jan 2001 13:16:43 -0500 (EST)
Message-ID: <3A5A040B.DFB38D19@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Neil Deason <ndeason@ubiquity.net>
Cc: Jo Hornsby <jhornsby@ubiquity.net>, Paul Francis <paul@francis.com>,
        sip@lists.bell-labs.com
Subject: Re: [SIP] question on received tag in via 
 header,draft-ietf-sip-rfc2543bis-02.txt
References: <000d01c0795a$880d1470$4e34c3c1@ubiquity.co.uk> <3A599F3C.16FBCE86@ubiquity.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 08 Jan 2001 13:16:43 -0500
Content-Transfer-Encoding: 7bit

Neil Deason wrote:
> 
> Jo Hornsby wrote:
> >
> > > Why is it that the receiver tag in the via header indicate the received
> > > network address but not also the received port (in section 6.47.2
> > > Receiver-tagged Via Header Fields)?
> >
> > In a nutshell: the port is generally not considered useful since
> > just because a client sends from a particular port, it doesn't
> > mean that it's also listening on that port.
> >
> > (I vote that this becomes a FAQ.)
> 
> I would further ask that we simply the SIP spec in this area.
> 6.47.1 Requests (p.77) and 6.47.2 Receiver-tagged Via Header
> Fields (p.78) both contain text about adding the received
> parameter. In 6.47.2 this crops up in relation to NATs. As the
> received param alone will not solve NAT issues can this
> reference be removed and these two sections consolidated into
> one?

I've combined the material into 6.47.2 and made up a multi-homed example
rather than a NAT example, removing mention of NATs altogether.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 14:35:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14731
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 14:35:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7859844339; Mon,  8 Jan 2001 13:36:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 476E644337
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 13:35:03 -0500 (EST)
Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f08JYHK10117;
	Mon, 8 Jan 2001 13:34:18 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f08JYH301381;
	Mon, 8 Jan 2001 13:34:17 -0600 (CST)
Received: from ericsson.com (pc050184.exu.ericsson.se [138.85.50.184]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA06027; Mon, 8 Jan 2001 13:34:16 -0600 (CST)
Message-ID: <3A5A162D.5080906@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Sparks <rsparks@dynamicsoft.com>
Cc: Henning Schulzrinne <hgs@cs.columbia.edu>,
        Jeff Mark <Jeff.Mark@dialogic.com>,
        "'Vijeth D'" <vijethd@rediffmail.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] Also field
References: <9BF66EBF6BEFD942915B4D4D45C051F3047488@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 08 Jan 2001 13:34:05 -0600
Content-Transfer-Encoding: 7bit

Correct. This is not a general solution that works for
everything. But I still think it is a useful option to
avoid 2K URIs (an exaggeration of course) :)

/sean

Robert Sparks wrote:

> This doesn't extend to many non-sip URLs.
> 
> 
>> -----Original Message-----
>> From: Sean Olson [mailto:sean.olson@ericsson.com]
>> Sent: Friday, January 05, 2001 3:57 PM
>> To: Henning Schulzrinne
>> Cc: Jeff Mark; 'Vijeth D'; sip@lists.bell-labs.com
>> Subject: Re: [SIP] Also field
>> 
>> 
>> 
>> 
>> Henning Schulzrinne wrote:
>> 
>> 
>>> To muddy the water a bit more with an unrelated topic, I 
>> 
>> wonder if some
>> 
>>> of the ugliness of encoding methods and headers in the Refer-To URL
>>> could be avoided by also attaching the message to be generated as a
>>> message/sip body.
>>> 
>>> Henning
>> 
>> I second that idea -- at least as an option in the absence of 
>> a Refer-To 
>> URL.
>> It also opens the door for nice things like S/MIME.
>> /sean
>> 
>> 
>> _______________________________________________
>> SIP mailing list
>> SIP@lists.bell-labs.com
>> http://lists.bell-labs.com/mailman/listinfo/sip
>> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 14:38:08 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14795
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 14:38:08 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D8A994434A; Mon,  8 Jan 2001 13:37:01 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by lists.bell-labs.com (Postfix) with ESMTP id BF15644346
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 13:36:07 -0500 (EST)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261)
 id <0G6U00601ZR8NM@firewall.mcit.com> for sip@lists.bell-labs.com; Mon,
 8 Jan 2001 19:35:32 +0000 (GMT)
Received: from pmismtp02.wcomnet.com ([166.38.62.37])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0G6U00LNKZR7KD@firewall.mcit.com>; Mon,
 08 Jan 2001 19:35:31 +0000 (GMT)
Received: from CONVERSION-DAEMON by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 id <0G6U00001ZR7X3@pmismtp02.wcomnet.com>; Mon,
 08 Jan 2001 19:35:31 +0000 (GMT)
Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com
 (PMDF V5.2-33 #42259) with SMTP id <0G6U00001ZR4WO@pmismtp02.wcomnet.com>;
 Mon, 08 Jan 2001 19:35:31 +0000 (GMT)
Received: from wcom.com ([166.46.16.94])
 by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259)
 with ESMTP id <0G6U00L9CZPNQ2@pmismtp02.wcomnet.com>; Mon,
 08 Jan 2001 19:35:19 +0000 (GMT)
From: Alan Johnston <alan.johnston@wcom.com>
Subject: Re: [SIP] Early media replacement.
To: Christian Huitema <huitema@exchange.microsoft.com>
Cc: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        SIP List <sip@lists.bell-labs.com>
Message-id: <3A5A1760.E4D82C37@wcom.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en] (Win98; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9E9@speak.dogfood>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 08 Jan 2001 13:39:13 -0600
Content-Transfer-Encoding: 7bit

Christian,

I disagree that the 183 itself is the hack.  It is an important and useful
provisional response.  However, using the 183 to establish a two-way early
media session is problematic, and I think it is a good idea to move the
complexity of this situation to a separate I-D which will probably have a
Require extension defined to indicate that a UA is ready to deal with the
complexity.  As Jonathan says, the base spec will still include 183, and
require a UA to listen for one-way early media packets as soon as it sends
an INVITE.

In my mind, the primary argument against getting rid of the 183 entirely
(which would force SIP/PSTN Gateways to map an Address Complete (ACM) or
Alerting message to a 200 OK) is that once you do so, you lose the ability
to indicate in a final response why a call failed.  Consider the case where
a call to the PSTN results in a Forward Don't Answer to another  number  in
the PSTN which is busy.  This could result in the following responses being
generated by the PSTN Gateway: a 183 Session Progress (indicating inband
alerting), a 181 Call Has Been Forwarded, followed by a 486 Busy Here final
response.  This lets the SIP Phone know exactly what happened to the call.
If we get rid of the 183, the PSTN Gateway would be forced to send a 200 OK
as soon as ringing took place.  Since this is a final response, no
indication of forwarding and busy could be sent besides the inband tones.
The busy tone would result in a BYE being sent - not very informative to the
SIP Phone.

In summary, I think this consensus on 183 and early media is a good one.  It
will allow any base SIP spec compliant UA to complete calls to the PSTN
through a Gateway without having to deal with the complexity of two-way
early media.

Also, the billing fraud issue you mention is not an issue in the PSTN.  You
can open up a two-way session on the IP side, but the PSTN Gateway will not
cut the PSTN trunk through in both directions until an answer has occurred
in the PSTN. Your audio path is still blocked in the PSTN.

Thanks,
Alan.


Christian Huitema wrote:

> >> So, that old 183 draft which has expired will be revived, and
> >> in it will be
> >> the stuff for handling basic early media at the SDP/SIP level.
> >>
> >There are other problems with deprecating early media by using
> >re-INVITE. Consider the case where an INVITE request is
> >forked by a proxy to both a SIP desktop client and a PSTn gateway.
> >If the gateway immediately sends a 200 OK on receipt of an INVUITE
> >(with a one-way SDP body to relay the remote ringback) then the
> >desktop client will never get a chance to answer the call.
> >Between two PSTN gateways you will have a race condition.
>
> Robert,
>
> It would be nice to collect a complete list of issues, so that we can
> really understand what is the rationale for the 183 extensions. Frankly,
> our main objective right now should be to keep SIP simple; from an
> architecture point of view, it is very desirable to use a single
> mechanism for many purposes (i.e. re-INVITE) rather than invent a
> specific hack for every specific problem (i.e. 183).
>
> Your "race condition" argument is not terribly convincing. The PSTN vs
> desktop case that you describe is not different from the possible
> race condition between a desktop and an answering machine, or, for
> that matter, of the possible race condition between two PSTN gateways.
> Forking an INVITE inherently creates a race condition: the first
> leg that responds with a 200-OK gets the call. Early media just makes
> the matter more confusing. Imagine a call forked to two PSTN gateways,
> one sending an early media that says "please dial 1 for an immediate
> connection, dial 2 for voice mail" and another that says "this is
> a protected line, please enter your PIN number." How exactly does
> 183 help in this case?
>
> In fact, the billing argument is not very convincing either. If we
> create a 183 response, we effectively create another way to establish
> a call. So, I can program my desktop to always answer with a 183
> response, a courtesy to my callers who won't be billed. Sure, the
> PSTN will time out eventually, but the time out is rather long --
> I will need to check, but it is at least 30 seconds, sufficient for
> most "answering machine" conditions. Besides, I can still send the
> 200 OK if the call lasts longer than the timer...
>
> -- Christian Huitema
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 14:42:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14878
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 14:42:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1E32544355; Mon,  8 Jan 2001 13:43:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from broadsoft.com (broadsoft.com [161.58.239.68])
	by lists.bell-labs.com (Postfix) with ESMTP id 3AD6C44352
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 13:42:13 -0500 (EST)
Received: from tate ([64.241.199.106]) by broadsoft.com (8.8.8) id OAA71318; Mon, 8 Jan 2001 14:42:00 -0500 (EST)
Message-ID: <033001c079ab$77eb4610$2b01a8c0@broadsoft.com>
From: "Brett Tate" <brett@broadsoft.com>
To: "SIPbell-labs" <sip@lists.bell-labs.com>
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 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Subject: [SIP] Open issues meeting?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 14:44:52 -0500
Content-Transfer-Encoding: 7bit

Has a date and location been identified for the 
interim SIP open issues meeting?

The VON Developers Conference was previously 
suggested, but I cannot recall if it was definite.



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 15:04:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15512
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 15:04:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1C74344340; Mon,  8 Jan 2001 14:05:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from femail2.rdc1.on.home.com (femail2.rdc1.on.home.com [24.2.9.89])
	by lists.bell-labs.com (Postfix) with ESMTP id 868D044337
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 14:04:33 -0500 (EST)
Received: from cr889345-a.ym1.on.wave.home.com ([24.43.6.252])
          by femail2.rdc1.on.home.com (InterMail vM.4.01.03.00 201-229-121)
          with SMTP
          id <20010108200417.CGMM21590.femail2.rdc1.on.home.com@cr889345-a.ym1.on.wave.home.com>;
          Mon, 8 Jan 2001 12:04:17 -0800
Received: by localhost with Microsoft MAPI; Mon, 8 Jan 2001 15:03:21 -0800
Message-ID: <01C07984.23EF4060.gross@fis.utoronto.ca>
From: Daniel Gross <gross@fis.utoronto.ca>
Reply-To: "gross@fis.utoronto.ca" <gross@fis.utoronto.ca>
To: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
Cc: "'gross@fis.utoronto.ca'" <gross@fis.utoronto.ca>
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: [SIP] "dedicated"  proxy servers and user application custom SIP headers ?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 15:03:20 -0800
Content-Transfer-Encoding: 7bit

Dear all,

I was referred to the SIP list and started to browse its archives. I 
thought to also post some specific questions i have in mind in the hope 
someone might be able to give me some quick feedback on them ...

I have started read about SIP as an infrastructure for flexible services 
creation, and have stumbled over an interesting paper by Jonathan Rosenberg 
et. al., where the authors describes the use of a SIP CGI interface for 
programming services. An admin (a trusted user) can provide SIP CGI scripts 
to SIP proxy servers, which are executed in an event driven manner when the 
server processes SIP protocol commands (quite similar to http processing). 
You can find the paper at: 
http://www.cs.columbia.edu/~jdrosen/papers/program_report.ps  .

The authors do not elaborate where the SIP proxy server that processes the 
SIP CGI scripts would reside in the "SIP network". I was wondering, for 
service applications that need user states over long periods of time 
(beyond single SIP transactions -- perhaps over the lifetime of the user 
being a customer to an operator), would there be a "dedicated" stateful 
user proxy servers "close" to the user agents, that would take care of the 
users preferences/policies/data, when he/she makes or receives a "call" (by 
invoking those CGI scripts)? Would infrastructure operators create such an 
application proxy server for each one of their customers?

I was also wondering what is the current state of the art in SIP, are such 
SIP CGI scripts utilized, or are perhaps java servlets used or other 
mechanisms (if at all)?

And perhaps if i can ask one more question. In the paper the authors 
describe how custom header information can be passed back and forth between 
the SIP proxy server and the CGI script. Is it possible in SIP to have 
custom headers generated by the users agent application (and/or by a 
"dedicated" user application proxy server), similar to user defined 
"X-headers" in Mime, which could then be utilized by the CGI scripts (or 
other 3rd party call control "plug-in" functions)?  Or does SIP not allow 
for custom header tags to be specified to be delivered to such 3rd call 
control "plug-ins", unless they are official header extension made by IETF 
( does SIP perhaps expects extensions to be placed in the body as, for 
example a mime message, thus making call control extension "media" 
specific).

appreciating any response

Daniel


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 15:19:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15876
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 15:19:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 08D2944352; Mon,  8 Jan 2001 14:20:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from selene.cps.intel.com (selene.cps.intel.com [192.198.165.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 8241544346
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 14:19:21 -0500 (EST)
Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204])
	by selene.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id MAA07693;
	Mon, 8 Jan 2001 12:19:08 -0800 (PST)
Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.204
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Mon, 08 Jan 2001 20:19:08 0000 (GMT)
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <Z4N050Z7>; Mon, 8 Jan 2001 12:19:06 -0800
Message-ID: <4148FEAAD879D311AC5700A0C969E8902D491F@orsmsx35.jf.intel.com>
From: "Gross, Gerhard" <gerhard.gross@intel.com>
To: "'gross@fis.utoronto.ca'" <gross@fis.utoronto.ca>,
        "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
Subject: RE: [SIP] "dedicated"  proxy servers and user application custom 
	SIP headers ?
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 12:19:06 -0800

Daniel,

> ... would there be a "dedicated" stateful 
> user proxy servers "close" to the user agents, that would 
> take care of the 
> users preferences/policies/data, when he/she makes or 
> receives a "call"

Such a server (policy server) is described in 
http://search.ietf.org/internet-drafts/draft-gross-sipaq-00.txt

Gery

        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        X                                         X
        X    Gerhard W. Gross, Ph.D.              X
        X    Intel                                X
        X    2111 NE 25th Ave                     X
        X    Hillsboro, OR 97124-5961, USA        X
        X    Policy Architecture Group            X
        X      - Internet and Communication Lab   X
        X    phone:    (503) 264-6389             X
        X    fax:      (503) 264-3483             X
        X    email:    gerhard.gross@intel.com    X
        X                                         X
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX



> -----Original Message-----
> From: Daniel Gross [mailto:gross@fis.utoronto.ca]
> Sent: Monday, January 08, 2001 3:03 PM
> To: 'sip@lists.bell-labs.com'
> Cc: 'gross@fis.utoronto.ca'
> Subject: [SIP] "dedicated" proxy servers and user application 
> custom SIP
> headers ?
> 
> 
> Dear all,
> 
> I was referred to the SIP list and started to browse its archives. I 
> thought to also post some specific questions i have in mind 
> in the hope 
> someone might be able to give me some quick feedback on them ...
> 
> I have started read about SIP as an infrastructure for 
> flexible services 
> creation, and have stumbled over an interesting paper by 
> Jonathan Rosenberg 
> et. al., where the authors describes the use of a SIP CGI 
> interface for 
> programming services. An admin (a trusted user) can provide 
> SIP CGI scripts 
> to SIP proxy servers, which are executed in an event driven 
> manner when the 
> server processes SIP protocol commands (quite similar to http 
> processing). 
> You can find the paper at: 
> http://www.cs.columbia.edu/~jdrosen/papers/program_report.ps  .
> 
> The authors do not elaborate where the SIP proxy server that 
> processes the 
> SIP CGI scripts would reside in the "SIP network". I was 
> wondering, for 
> service applications that need user states over long periods of time 
> (beyond single SIP transactions -- perhaps over the lifetime 
> of the user 
> being a customer to an operator), would there be a 
> "dedicated" stateful 
> user proxy servers "close" to the user agents, that would 
> take care of the 
> users preferences/policies/data, when he/she makes or 
> receives a "call" (by 
> invoking those CGI scripts)? Would infrastructure operators 
> create such an 
> application proxy server for each one of their customers?
> 
> I was also wondering what is the current state of the art in 
> SIP, are such 
> SIP CGI scripts utilized, or are perhaps java servlets used or other 
> mechanisms (if at all)?
> 
> And perhaps if i can ask one more question. In the paper the authors 
> describe how custom header information can be passed back and 
> forth between 
> the SIP proxy server and the CGI script. Is it possible in 
> SIP to have 
> custom headers generated by the users agent application (and/or by a 
> "dedicated" user application proxy server), similar to user defined 
> "X-headers" in Mime, which could then be utilized by the CGI 
> scripts (or 
> other 3rd party call control "plug-in" functions)?  Or does 
> SIP not allow 
> for custom header tags to be specified to be delivered to 
> such 3rd call 
> control "plug-ins", unless they are official header extension 
> made by IETF 
> ( does SIP perhaps expects extensions to be placed in the 
> body as, for 
> example a mime message, thus making call control extension "media" 
> specific).
> 
> appreciating any response
> 
> Daniel
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 16:23:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16935
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 16:23:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C48FD4433A; Mon,  8 Jan 2001 15:24:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 6427E44337
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 15:23:20 -0500 (EST)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257)
 id <0G6V007014D86X@firewall.mcit.com> for sip@lists.bell-labs.com; Mon,
 8 Jan 2001 21:15:08 +0000 (GMT)
Received: from pmismtp03.wcomnet.com ([166.38.62.38])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0G6V001CI4D68O@firewall.mcit.com>; Mon,
 08 Jan 2001 21:15:08 +0000 (GMT)
Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258)
 id <0G6V00G014CQ7Z@pmismtp03.wcomnet.com>; Mon,
 08 Jan 2001 21:14:50 +0000 (GMT)
Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0G6V00E0147TR2@pmismtp03.wcomnet.com>;
 Mon, 08 Jan 2001 21:14:48 +0000 (GMT)
Received: from hsinnreich ([166.35.226.44])
 by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258)
 with SMTP id <0G6V00BL544TPI@pmismtp03.wcomnet.com>; Mon,
 08 Jan 2001 21:10:09 +0000 (GMT)
From: Henry Sinnreich <henry.sinnreich@wcom.com>
Subject: RE: [SIP] "dedicated"  proxy servers and user application custom	SIP
 headers ?
In-reply-to: <4148FEAAD879D311AC5700A0C969E8902D491F@orsmsx35.jf.intel.com>
To: "Gross, Gerhard" <gerhard.gross@intel.com>, gross@fis.utoronto.ca,
        sip@lists.bell-labs.com
Message-id: <NEBBLDFFKGAJDPBENMDNKEKODGAA.henry.sinnreich@wcom.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 08 Jan 2001 15:10:02 -0600
Content-Transfer-Encoding: 7bit

Network policies are described as in the attached. Personal preferences
reside in the SIP server, see
http://search.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-03.txt

Henry

-----Original Message-----
From: sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Gross, Gerhard
Sent: Monday, January 08, 2001 2:19 PM
To: 'gross@fis.utoronto.ca'; 'sip@lists.bell-labs.com'
Subject: RE: [SIP] "dedicated" proxy servers and user application custom
SIP headers ?


Daniel,

> ... would there be a "dedicated" stateful
> user proxy servers "close" to the user agents, that would
> take care of the
> users preferences/policies/data, when he/she makes or
> receives a "call"

Such a server (policy server) is described in
http://search.ietf.org/internet-drafts/draft-gross-sipaq-00.txt

Gery

        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        X                                         X
        X    Gerhard W. Gross, Ph.D.              X
        X    Intel                                X
        X    2111 NE 25th Ave                     X
        X    Hillsboro, OR 97124-5961, USA        X
        X    Policy Architecture Group            X
        X      - Internet and Communication Lab   X
        X    phone:    (503) 264-6389             X
        X    fax:      (503) 264-3483             X
        X    email:    gerhard.gross@intel.com    X
        X                                         X
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX



> -----Original Message-----
> From: Daniel Gross [mailto:gross@fis.utoronto.ca]
> Sent: Monday, January 08, 2001 3:03 PM
> To: 'sip@lists.bell-labs.com'
> Cc: 'gross@fis.utoronto.ca'
> Subject: [SIP] "dedicated" proxy servers and user application
> custom SIP
> headers ?
>
>
> Dear all,
>
> I was referred to the SIP list and started to browse its archives. I
> thought to also post some specific questions i have in mind
> in the hope
> someone might be able to give me some quick feedback on them ...
>
> I have started read about SIP as an infrastructure for
> flexible services
> creation, and have stumbled over an interesting paper by
> Jonathan Rosenberg
> et. al., where the authors describes the use of a SIP CGI
> interface for
> programming services. An admin (a trusted user) can provide
> SIP CGI scripts
> to SIP proxy servers, which are executed in an event driven
> manner when the
> server processes SIP protocol commands (quite similar to http
> processing).
> You can find the paper at:
> http://www.cs.columbia.edu/~jdrosen/papers/program_report.ps  .
>
> The authors do not elaborate where the SIP proxy server that
> processes the
> SIP CGI scripts would reside in the "SIP network". I was
> wondering, for
> service applications that need user states over long periods of time
> (beyond single SIP transactions -- perhaps over the lifetime
> of the user
> being a customer to an operator), would there be a
> "dedicated" stateful
> user proxy servers "close" to the user agents, that would
> take care of the
> users preferences/policies/data, when he/she makes or
> receives a "call" (by
> invoking those CGI scripts)? Would infrastructure operators
> create such an
> application proxy server for each one of their customers?
>
> I was also wondering what is the current state of the art in
> SIP, are such
> SIP CGI scripts utilized, or are perhaps java servlets used or other
> mechanisms (if at all)?
>
> And perhaps if i can ask one more question. In the paper the authors
> describe how custom header information can be passed back and
> forth between
> the SIP proxy server and the CGI script. Is it possible in
> SIP to have
> custom headers generated by the users agent application (and/or by a
> "dedicated" user application proxy server), similar to user defined
> "X-headers" in Mime, which could then be utilized by the CGI
> scripts (or
> other 3rd party call control "plug-in" functions)?  Or does
> SIP not allow
> for custom header tags to be specified to be delivered to
> such 3rd call
> control "plug-ins", unless they are official header extension
> made by IETF
> ( does SIP perhaps expects extensions to be placed in the
> body as, for
> example a mime message, thus making call control extension "media"
> specific).
>
> appreciating any response
>
> Daniel
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 17:05:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17543
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 17:05:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4CAF344342; Mon,  8 Jan 2001 16:06:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196])
	by lists.bell-labs.com (Postfix) with ESMTP id 9C8E244338
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 16:05:49 -0500 (EST)
Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174])
	by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id QAA12140;
	Mon, 08 Jan 2001 16:02:00 -0600
Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0)
	id <YB5MRQTP>; Mon, 8 Jan 2001 15:58:12 -0600
Message-ID: <DBD1CC7CE357D211AECC009027158FD103ACB2F7@itmail-ict1-imc.wichita.brite.com>
From: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com>
To: Alan Johnston <alan.johnston@wcom.com>,
        Christian Huitema <huitema@exchange.microsoft.com>
Cc: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        SIP List <sip@lists.bell-labs.com>
Subject: RE: [SIP] Early media replacement.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 15:58:09 -0600

I'd like to make a few comments on this subject.

First, I agree that 183 is useful.  However, I don't see it as 
a mapping to an ACM message.  180 serves that 
purpose, I believe I've seen it documented in some ISUP 
interworking I-Ds.  What I do see 183 useful for is to stop 
local ringback at the UAC.  The UAS (PSTN GW) can 
provide remote ringback without sending a 183 (since the 
UAC should be prepared to receive and render media after 
sending the INVITE) but the user experience may be 
strange (hearing two sources of ringback).  183 has other 
uses I suppose as Alan points out but I wouldn't use it to 
establish a two-way media session because my 
applications can separate start of billing from a particular 
200.  But I'm just thinking of my own applications at this 
point.

I too would like to see a complete list of issues before 
any changes are made to what's currently specified.  I 
remember one complaint of a SIP phone displaying 
ringing but the user could hear busy tone.  If the UAS 
sent a 183 prior to sending busy tone that problem lies 
with the UAC and not the 183 or early media.  I can also 
see the possibility of RTP endpoints needing address and 
port information to exchange session attributes to get 
even the one-way media to be processed and rendered at 
the UAC but this is an additional requirement on the UAS 
if needed.

Regards,
Bert


> -----Original Message-----
> From: Alan Johnston [mailto:alan.johnston@wcom.com]
> Sent: Monday, January 08, 2001 2:39 PM
> To: Christian Huitema
> Cc: Fairlie-Cuninghame, Robert; Jonathan Rosenberg; SIP List
> Subject: Re: [SIP] Early media replacement.
> 
> 
> Christian,
> 
> I disagree that the 183 itself is the hack.  It is an 
> important and useful
> provisional response.  However, using the 183 to establish a 
> two-way early
> media session is problematic, and I think it is a good idea 
> to move the
> complexity of this situation to a separate I-D which will 
> probably have a
> Require extension defined to indicate that a UA is ready to 
> deal with the
> complexity.  As Jonathan says, the base spec will still 
> include 183, and
> require a UA to listen for one-way early media packets as 
> soon as it sends
> an INVITE.
> 
> In my mind, the primary argument against getting rid of the 
> 183 entirely
> (which would force SIP/PSTN Gateways to map an Address 
> Complete (ACM) or
> Alerting message to a 200 OK) is that once you do so, you 
> lose the ability
> to indicate in a final response why a call failed.  Consider 
> the case where
> a call to the PSTN results in a Forward Don't Answer to 
> another  number  in
> the PSTN which is busy.  This could result in the following 
> responses being
> generated by the PSTN Gateway: a 183 Session Progress 
> (indicating inband
> alerting), a 181 Call Has Been Forwarded, followed by a 486 
> Busy Here final
> response.  This lets the SIP Phone know exactly what happened 
> to the call.
> If we get rid of the 183, the PSTN Gateway would be forced to 
> send a 200 OK
> as soon as ringing took place.  Since this is a final response, no
> indication of forwarding and busy could be sent besides the 
> inband tones.
> The busy tone would result in a BYE being sent - not very 
> informative to the
> SIP Phone.
> 
> In summary, I think this consensus on 183 and early media is 
> a good one.  It
> will allow any base SIP spec compliant UA to complete calls 
> to the PSTN
> through a Gateway without having to deal with the complexity 
> of two-way
> early media.
> 
> Also, the billing fraud issue you mention is not an issue in 
> the PSTN.  You
> can open up a two-way session on the IP side, but the PSTN 
> Gateway will not
> cut the PSTN trunk through in both directions until an answer 
> has occurred
> in the PSTN. Your audio path is still blocked in the PSTN.
> 
> Thanks,
> Alan.
> 
> 
> Christian Huitema wrote:
> 
> > >> So, that old 183 draft which has expired will be revived, and
> > >> in it will be
> > >> the stuff for handling basic early media at the SDP/SIP level.
> > >>
> > >There are other problems with deprecating early media by using
> > >re-INVITE. Consider the case where an INVITE request is
> > >forked by a proxy to both a SIP desktop client and a PSTn gateway.
> > >If the gateway immediately sends a 200 OK on receipt of an INVUITE
> > >(with a one-way SDP body to relay the remote ringback) then the
> > >desktop client will never get a chance to answer the call.
> > >Between two PSTN gateways you will have a race condition.
> >
> > Robert,
> >
> > It would be nice to collect a complete list of issues, so 
> that we can
> > really understand what is the rationale for the 183 
> extensions. Frankly,
> > our main objective right now should be to keep SIP simple; from an
> > architecture point of view, it is very desirable to use a single
> > mechanism for many purposes (i.e. re-INVITE) rather than invent a
> > specific hack for every specific problem (i.e. 183).
> >
> > Your "race condition" argument is not terribly convincing. 
> The PSTN vs
> > desktop case that you describe is not different from the possible
> > race condition between a desktop and an answering machine, or, for
> > that matter, of the possible race condition between two 
> PSTN gateways.
> > Forking an INVITE inherently creates a race condition: the first
> > leg that responds with a 200-OK gets the call. Early media 
> just makes
> > the matter more confusing. Imagine a call forked to two 
> PSTN gateways,
> > one sending an early media that says "please dial 1 for an immediate
> > connection, dial 2 for voice mail" and another that says "this is
> > a protected line, please enter your PIN number." How exactly does
> > 183 help in this case?
> >
> > In fact, the billing argument is not very convincing either. If we
> > create a 183 response, we effectively create another way to 
> establish
> > a call. So, I can program my desktop to always answer with a 183
> > response, a courtesy to my callers who won't be billed. Sure, the
> > PSTN will time out eventually, but the time out is rather long --
> > I will need to check, but it is at least 30 seconds, sufficient for
> > most "answering machine" conditions. Besides, I can still send the
> > 200 OK if the call lasts longer than the timer...
> >
> > -- Christian Huitema
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 17:48:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18112
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 17:48:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 094B944338; Mon,  8 Jan 2001 16:49:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from deneb.mtghouse.com (064-031-067-067.inaddr.vitts.com [64.31.67.67])
	by lists.bell-labs.com (Postfix) with SMTP id 56EAC44337
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 16:48:53 -0500 (EST)
Received: (qmail 56308 invoked from network); 8 Jan 2001 22:48:40 -0000
Received: from deneb.mtghouse.com (HELO deneb) (192.168.1.4)
  by deneb.mtghouse.com with SMTP; 8 Jan 2001 22:48:40 -0000
From: "Jon A. LaRosa" <jal@mtghouse.com>
X-Sender: jal@deneb
To: sip@lists.bell-labs.com
Message-ID: <Pine.BSF.3.95.1010108174638.37404y-100000@deneb>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [SIP] Section 16.2.2
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 17:48:40 -0500 (EST)

Why is the second Via field 'SIP/2.0/UDP north.east.isi.edu' rather than 
'SIP/2.0/UDP mouse.wonderful.com'?


Thanks.

Jon


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 18:06:50 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18325
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 18:06:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8F71544340; Mon,  8 Jan 2001 17:07:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id A5ECC4434B
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 17:06:17 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA03365;
	Mon, 8 Jan 2001 18:06:00 -0500 (EST)
Message-ID: <3A5A47D7.564068EC@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Jon A. LaRosa" <jal@mtghouse.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Section 16.2.2
References: <Pine.BSF.3.95.1010108174638.37404y-100000@deneb>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 08 Jan 2001 18:05:59 -0500
Content-Transfer-Encoding: 7bit

"Jon A. LaRosa" wrote:
> 
> Why is the second Via field 'SIP/2.0/UDP north.east.isi.edu' rather than
> 'SIP/2.0/UDP mouse.wonderful.com'?

Already fixed in the upcoming -03.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 18:21:50 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18524
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 18:21:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AB86544342; Mon,  8 Jan 2001 17:22:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by lists.bell-labs.com (Postfix) with ESMTP id D3DDE44341
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 17:21:41 -0500 (EST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Mon, 8 Jan 2001 15:19:05 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Jan 2001 15:19:50 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532);
	 Mon, 8 Jan 2001 15:19:50 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0
content-class: urn:content-classes:message
Subject: RE: [SIP] Early media replacement.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9EB@speak.dogfood>
Thread-Topic: [SIP] Early media replacement.
Thread-Index: AcB5v2KNBAr4ztkORP2SQN0S7bTNVQACUCwQ
From: "Christian Huitema" <huitema@exchange.microsoft.com>
To: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com>,
        "Alan Johnston" <alan.johnston@wcom.com>
Cc: "SIP List" <sip@lists.bell-labs.com>
X-OriginalArrivalTime: 08 Jan 2001 23:19:50.0635 (UTC) FILETIME=[7FD3D3B0:01C079C9]
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 15:19:52 -0800
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA18524

One thing is to provide a notification of partial call completion, and
another is establish a two-ways circuit. There is no need of carrying an
SDP field in a provisional response in order to provide audio feedback:
sending RTP packets to the address advertised in the INVITE ought to be
sufficient. A lot of the complexity cause by the proposed 183 disappears
if that response does not carry an SDP payload.

On the other hand, if one allows an SDP payload in a provisional
response, for example for collecting DTMF digits or voice commands, then
the PSTN gateway must open a two ways circuit, and the billing fraud is
enabled.

-- Christian Huitema

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 19:15:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18962
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 19:15:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CC77244340; Mon,  8 Jan 2001 18:16:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from dcn.ssu.ac.kr (dcn.ssu.ac.kr [203.253.2.104])
	by lists.bell-labs.com (Postfix) with ESMTP id DA9C244338
	for <SIP@lists.bell-labs.com>; Mon,  8 Jan 2001 18:15:00 -0500 (EST)
Received: from softgear ([203.253.3.209])
	by dcn.ssu.ac.kr (8.10.1/8.10.1) with SMTP id f0908Sn20187
	for <SIP@lists.bell-labs.com>; Tue, 9 Jan 2001 09:08:28 +0900 (KST)
From: =?ks_c_5601-1987?B?sO28rrCp?= <softgear@dcn.ssu.ac.kr>
To: <SIP@lists.bell-labs.com>
Message-ID: <KIEFJGHGPFLKMLPOFDOLIEABCBAA.softgear@dcn.ssu.ac.kr>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Importance: Normal
Subject: [SIP] SDP o,c field for IPv6.?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 09:13:33 +0900
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id TAA18962

Hello?
If I am using IPv6,
What should I use as network type?
ex)
	c=IN IP6 3456:1234::1/32
	c=IN6 IP6 3456:1234::1/32
which one is right?
			
				Soft.ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËb�ú?


From sip-admin@lists.bell-labs.com  Mon Jan  8 20:03:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19202
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 20:03:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 12E8E44346; Mon,  8 Jan 2001 19:04:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 1E58444340
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 19:03:40 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0913TD30332
	for sip@lists.bell-labs.com; Mon, 8 Jan 2001 19:03:29 -0600 (CST)
Resent-Message-Id: <200101090103.f0913TD30332@fdd.com>
From: Rick Dean <siplist@fdd.com>
To: Christian Huitema <huitema@exchange.microsoft.com>
Subject: Re: [SIP] Early media replacement.
Message-ID: <20010108190113.A7076@fdd.com>
References: <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9E9@speak.dogfood>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9E9@speak.dogfood>; from huitema@exchange.microsoft.com on Mon, Jan 08, 2001 at 08:38:35AM -0800
Resent-From: siplist@fdd.com
Resent-Date: Mon, 8 Jan 2001 19:02:09 -0600
Resent-To: sip@lists.bell-labs.com
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 19:01:13 -0600
Resent-Sender: sip-admin@lists.bell-labs.com


If we keep early media, then we need to keep 
the 183 cruft, otherwise parallel forking proxies
can't know they have forked to two simultaneous
streaming media locations, a no-no.  Never mind 
the UAC problems and possible non-support for mixing;
mixed ringbacks (even without busy & errors) 
do not make sense to end users.  My limited 
focus group testing is resoundingly negative.  
They hang up.

Gateways send early media when they don't
know what the media means.  Outlawing early
media doesn't mean they have to send 200 okay
immediately, unless they can't tell it is
ringback.  

If gateways can't tell anything, then uninformed
non-200 responses are not useful either.
Users do not listen to 30 seconds of 
busy indication, just in case the
forking proxy tries to serial fork another location.

In summary, if not even SS7 gateways can tell
what the media means all the time for at least
some destinations, then forking with PSTN is 
f*cked.

Even if you allow 183 & early media for forking
you generally don't get informative
4xx responses from gateways because
they want an error session: "The number you
have dialed is disconnected, the new number
is 888-555-1212".  I am still waiting to
flame someone for suggesting we support 
"late media". :-)

Early media doesn't help.  Let's kill it.
If gateway builders figure out a way to
detect ringback, and thus send 180, we can 
have PSTN forking again.

Cheers,
Rick
rick_dean@3com.com

P.S. Please forgive me if I always write from the
perspective of a UA (as opposed to a proxy or
back-to-back UA) without noting it.


On Mon, Jan 08, 2001 at 08:38:35AM -0800, Christian Huitema wrote:
> >> So, that old 183 draft which has expired will be revived, and 
> >> in it will be 
> >> the stuff for handling basic early media at the SDP/SIP level. 
> >> 
> >There are other problems with deprecating early media by using 
> >re-INVITE. Consider the case where an INVITE request is 
> >forked by a proxy to both a SIP desktop client and a PSTn gateway. 
> >If the gateway immediately sends a 200 OK on receipt of an INVUITE 
> >(with a one-way SDP body to relay the remote ringback) then the 
> >desktop client will never get a chance to answer the call. 
> >Between two PSTN gateways you will have a race condition.
> 
> Robert,
> 
> It would be nice to collect a complete list of issues, so that we can
> really understand what is the rationale for the 183 extensions. Frankly,
> our main objective right now should be to keep SIP simple; from an
> architecture point of view, it is very desirable to use a single
> mechanism for many purposes (i.e. re-INVITE) rather than invent a
> specific hack for every specific problem (i.e. 183). 
> 
> Your "race condition" argument is not terribly convincing. The PSTN vs
> desktop case that you describe is not different from the possible
> race condition between a desktop and an answering machine, or, for
> that matter, of the possible race condition between two PSTN gateways.
> Forking an INVITE inherently creates a race condition: the first 
> leg that responds with a 200-OK gets the call. Early media just makes
> the matter more confusing. Imagine a call forked to two PSTN gateways,
> one sending an early media that says "please dial 1 for an immediate
> connection, dial 2 for voice mail" and another that says "this is
> a protected line, please enter your PIN number." How exactly does
> 183 help in this case?
> 
> In fact, the billing argument is not very convincing either. If we
> create a 183 response, we effectively create another way to establish
> a call. So, I can program my desktop to always answer with a 183
> response, a courtesy to my callers who won't be billed. Sure, the
> PSTN will time out eventually, but the time out is rather long --
> I will need to check, but it is at least 30 seconds, sufficient for
> most "answering machine" conditions. Besides, I can still send the
> 200 OK if the call lasts longer than the timer...
> 
> -- Christian Huitema
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 21:57:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21182
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 21:57:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 73F5044338; Mon,  8 Jan 2001 20:58:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from rwcxch02.clarent.com (unknown [208.205.112.2])
	by lists.bell-labs.com (Postfix) with ESMTP id C218744337
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 20:57:40 -0500 (EST)
Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21)
	id <WV1DGX8M>; Mon, 8 Jan 2001 18:56:39 -0800
Received: from rwcjfmule01 (10.1.1.2 [10.1.1.2]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id WV1DGX8J; Mon, 8 Jan 2001 18:56:28 -0800
From: Jean-Francois Mule <jfmule@clarent.com>
Reply-To: Jean-Francois Mule <jfmule@clarent.com>
To: "'Brian Stucker'" <bstucker@nortelnetworks.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Sean Olson'" <sean.olson@ericsson.com>,
        "'Dean Willis'" <dean.willis@softarmor.com>,
        "'IETF SIP (E-mail)'" <sip@lists.bell-labs.com>
Cc: "'Joon Maeng'" <joon_maeng@vtel.com>,
        "'Dave Walker'" <drwalker@ss8networks.com>, klingle@cisco.com,
        sip-mib@egroups.com
Subject: RE: [SIP] Discussion of Default Timers & sip mib
Message-ID: <012301c079e7$ba990290$e54b010a@rwcjfmule01>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 18:56:13 -0800
Content-Transfer-Encoding: 7bit

After reading through the 15 emails sent on 1/2 & 1/3/2001, I'd like to
summarize the discussion on default timers in the context of the sip-mib.

we need:
-timer configs for all sip methods supported by sip UA, proxy servers
(stateful case).  No need for timer config for registrar servers.
-config timers to be read write so that management systems can set/reset
based on network topology.
- default values in the MIB will be defined according to rfc - there is
apparently no consensus to change the default values from this thread.

In summary, the following additions need to be done for the next draft of
sip-mib-01:
1. stateful proxy servers need timer configurations as well (so far, we only
have 1 object for INVITE timeout but it happens to be expressed in seconds -
need to change to ms).  The proposal is to replicate the sipUACfgtimer table
in the sip-server mib.
2. Default values need to be added (DEFVAL for each mib object)

Please check the the config timers in sip-mib-draft-01 and make comments
(the sipReRegister timer should be redefined so do not bother commenting on
this one).  If we have missed anything from the thread, please add.
Thank you,
Jean-Francois.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan  8 23:58:50 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23446
	for <sip-archive@odin.ietf.org>; Mon, 8 Jan 2001 23:58:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2EA8544338; Mon,  8 Jan 2001 22:59:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from nw128.netaddress.usa.net (nw128.netaddress.usa.net [204.68.24.28])
	by lists.bell-labs.com (Postfix) with SMTP id 232F644337
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 22:58:53 -0500 (EST)
Received: (qmail 14473 invoked by uid 60001); 9 Jan 2001 04:58:41 -0000
Message-ID: <20010109045841.14472.qmail@nw128.netaddress.usa.net>
Received: from 204.68.24.28 by nw128 for [203.197.178.240] via web-mailer(34FM.0700.15.02) on Tue Jan  9 04:58:41 GMT 2001
From: Nishith Chudasama <nishith76@usa.net>
To: Vijay Gurbani <vkg@lucent.com>, Nishith Chudasama <nishith76@usa.net>
Subject: Re: [Re: [SIP] REGISTRAR functions.]
Cc: sip@lists.bell-labs.com
X-Mailer: USANET web-mailer (34FM.0700.15.02)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 8 Jan 2001 21:58:41 MST
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA23446

RFC 2453 is for RIP. I couldn't find anything related to REGISTRAR or REGISTER
related to SIP.
Kindly let me know if it was a typing mistake.

Regarding communication between SIP server and REGISTRAR/Location server), I
wanted to know the messages. For example, INVITE, OPTIONS etc.

If Registrar and Location server are not colocated, aint there any specs for
implementing them? If it is implementation dependant, I think InterOpt will be
a big problem....

Nishith.

Vijay Gurbani <vkg@lucent.com> wrote:
Nishith Chudasama wrote:
> 
> Following are the queries regarding SIP REGISTRAR implementation. Kindly 
> let me know if anybody has the solution.....
> 
> 1. Where can I get the specifications to develop a SIP Registrar?

RFC 2453 (and subsequent bis modifications)

> 2. For a particular USER registration, what all information from the 
> REGISTER request should be stored by Registrar?(Till the registration 
> expires...)

Presumably, at least the Contact and Expire information.  If the REGISTER 
request had a CPL (or any other) payload, that'll need to be stored as well.
 
> 3. If the REGISTRAR and Location server are not co-located, How and what 
> to inform the Location server following a REGISTER request from a User?

Implementation dependent.
 
> 4. What are the messages exchanged between a SIP proxy/Redirect server and 
> a Location server/Registrar?

If they are co-located, a functional API would suffice.  If not, SIP itself
could be a candidate.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184


____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 01:18:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25598
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 01:18:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 76ED544338; Tue,  9 Jan 2001 00:19:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 68D3444337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 00:18:49 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA16111;
	Tue, 9 Jan 2001 01:21:03 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBYLZ>; Tue, 9 Jan 2001 01:15:20 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB015@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Nishith Chudasama'" <nishith76@usa.net>, Vijay Gurbani <vkg@lucent.com>
Cc: sip@lists.bell-labs.com
Subject: RE: [Re: [SIP] REGISTRAR functions.]
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 01:15:09 -0500



 

> -----Original Message-----
> From: Nishith Chudasama [mailto:nishith76@usa.net]
> Sent: Monday, January 08, 2001 11:59 PM
> To: Vijay Gurbani; Nishith Chudasama
> Cc: sip@lists.bell-labs.com
> Subject: Re: [Re: [SIP] REGISTRAR functions.]
> 
> 
> RFC 2453 is for RIP. I couldn't find anything related to 
> REGISTRAR or REGISTER
> related to SIP.
> Kindly let me know if it was a typing mistake.

Its RFC2543. 

One can also find things easily on the web by using search engines. Typing
"sip" into www.google.com, for example, yields as the first result:

http://www.cs.columbia.edu/sip/

which has some tutorials, FAQs, links to standards, and so on. 

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 01:29:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27096
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 01:29:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7FFEC44338; Tue,  9 Jan 2001 00:30:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id F2E1944336
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 00:29:00 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA16139;
	Tue, 9 Jan 2001 01:31:34 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBYMA>; Tue, 9 Jan 2001 01:25:51 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB016@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Rick Dean'" <siplist@fdd.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Early media replacement.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 01:25:41 -0500



 

> -----Original Message-----
> From: Rick Dean [mailto:siplist@fdd.com]
> Sent: Monday, January 08, 2001 8:01 PM
> To: sip@lists.bell-labs.com
> Subject: Re: [SIP] Early media replacement.
> 
> 
> 
> If we keep early media, then we need to keep 
> the 183 cruft, otherwise parallel forking proxies
> can't know they have forked to two simultaneous
> streaming media locations, a no-no. 

In practice, I doubt calls to PSTN numbers will fork anyway. 
That aside, a UA can deal with the multiplicity of streams in the
standard RTP way - sort them out by SSRC, and play one and/or mix
them as it sees fit. It needs to be able to do that whether or not
the 183 message is present. 

> Early media doesn't help.  Let's kill it.

I'm afraid that this will simply not fly. 
Gateways will, far too often, need to send
media in the reverse direction without knowing
what it is. The reality is that forking will be 
problematic for PSTN interworking.
Thats a reality of PSTN interoperability.
Whining about it will not cause the problem to go 
away. 

I am unwilling to dismiss PSTN interoperability as 
an important issue for SIP. My hope is to allow a 
normal SIP UA phone or PC client to not have to
worry too much about it. The proposed solution
of receiving media after INVITE (with the caveat that
your RTP implementation needs to be correct and sort
by SSRC any media that comes), alleviates any complex
work on the side of a UA, and still pretty much
works.

-Jonathan R.


---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 01:48:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29510
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 01:48:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F3D4D44338; Tue,  9 Jan 2001 00:49:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id C24C644337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 00:48:36 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA16197;
	Tue, 9 Jan 2001 01:51:06 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBYM3>; Tue, 9 Jan 2001 01:45:22 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB017@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Itamar Gilad'" <ItamarG@tlv.radvision.com>,
        "'SIP List'" <sip@lists.bell-labs.com>
Subject: RE: [SIP] is SIP backward compatible?
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="windows-1255"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 01:45:20 -0500



 

> -----Original Message-----
> From: Itamar Gilad [mailto:ItamarG@tlv.radvision.com]
> Sent: Thursday, January 04, 2001 12:23 PM
> To: 'SIP List'
> Subject: [SIP] is SIP backward compatible?
> 
> 
> Everybody,
> I'm looking for some guidance in regard to the backward 
> compatibility of
> SIP.  From following the mailing list and relevant events I 
> know that an
> effort is made not to break existing implementations, yet a 
> pure RFC2543
> might have interop problems with a pure bis-02 implementation 
> because of
> some of the changes made.  My questions:
> * What are the rules that determine this?  
> * Are the compatibility-breaking changes about to stop once 
> bis-02 goes RFC?
> Anytime?
> * Is there some sort of general IETF guideline to this matter?

We've been attempting to maintain compatibility as much as possible. The
primary, but to date implicit, guideline has been that, in the worse case, a
change should cause the behavior between an rfc2543bis and rfc2543 entity to
be no different than if both were only rfc2543 compliant. In other words,
certain things are broken and/or unspecified in rfc2543. It may be that the
fix in bis will not correct the problem unless some or all of the entities
are bis compliant. I think this is a reasonable thing to do.

There is only one thing I know of that is formally not backward compatible -
the addition of extension parameters in several places. A very strict parser
might bomb on headers with extension parameters although none were allowed
according to rfc2543. Fortunately, most implementations have been tracking
the changes in the drafts, and I don't think this will be a problem in
practice. 

If you know of anything specific that has been added or changed that breaks
backwards compatibility, please let us know.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 01:50:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29813
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 01:50:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C6C4444353; Tue,  9 Jan 2001 00:51:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 2A4B444338
	for <SIP@lists.bell-labs.com>; Tue,  9 Jan 2001 00:50:50 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA16221;
	Tue, 9 Jan 2001 01:53:24 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBYM4>; Tue, 9 Jan 2001 01:47:41 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB018@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'james jack'" <sipjames@yahoo.com>, SIP@lists.bell-labs.com
Subject: RE: [SIP] A foolish idea
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 01:47:40 -0500



 

> -----Original Message-----
> From: james jack [mailto:sipjames@yahoo.com]
> Sent: Thursday, January 04, 2001 10:33 AM
> To: SIP@lists.bell-labs.com
> Subject: [SIP] A foolish idea
> 
> 
> Dear All:
>   I have foolish idea on Via, for via, On page 57 of
> RFC2543bis02, which describes as the following"
> " Each subsequent proxy server that sends the request
> onwards MUST add its own additional Via field before
> any existing Via fields. " It means whether the proxy
> to be stateful or stateless must insert via
> information in the Via header.
>     In my opinion, I think for stateless proxy, there
> is no need to insert it's via information in the Via
> header. thus can save the time for parsing the SIP
> message. Then stateless proxy received one request
> message, there is no need for it to parse the whole
> message, only parse the Request-Line,using DNS to 
> get the next hop of the request?
>     But this idea also has some disadvantage, for
> example, if not parsed fully, how can the stateless
> proxy check the location information?

The primary problem is that this does not work.

The reason is that if a proxy doesn't insert a Via header, the
hop after the proxy will see a different source address than the
via header. It will thusly still send responses back to the
proxy anyway, but to the port in the via header. Of course, this 
port is whatever the hop PREVIOUS to that stateless proxy is listening
on. As such, this stateless proxy would need to listen on every single
UDP port. Not a very good thing.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 01:54:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00332
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 01:54:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E140C4435A; Tue,  9 Jan 2001 00:55:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id E50E344353
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 00:54:37 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA16249;
	Tue, 9 Jan 2001 01:56:45 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBYM6>; Tue, 9 Jan 2001 01:51:02 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB019@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Deepak  Mohan'" <deepakwarrier@rediffmail.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] "method" parameter in "contact"
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 01:50:59 -0500



 

> -----Original Message-----
> From: Deepak Mohan [mailto:deepakwarrier@rediffmail.com]
> Sent: Thursday, January 04, 2001 6:54 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] "method" parameter in "contact"
> 
> 
> In which request/response will the "contact" header have the 
> "method" parameter, and what is the use?

The primary use for the method parameter was when a URL was embedded in a
web page. It indicates what method the UA should use. Very useful for things
like:

<html>
You can send me an <a
href="sip:jdrosen@dynamicsoft.com;method=message">Instant Message</a>.
</html>

I don't see much use in the method parameter within a SIP request itself.

The SIP for presence documents talk about a "methods" parameter (NOTE the
plural), but this is not a URL parameter, its a Contact header parameter,
defined in the caller preferences specification.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 02:03:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06216
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 02:03:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C47564434F; Tue,  9 Jan 2001 01:04:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 7E63E44336
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 01:03:09 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA16335;
	Tue, 9 Jan 2001 02:05:15 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBYNP>; Tue, 9 Jan 2001 01:59:32 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB01A@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Vijeth  D'" <vijethd@rediffmail.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] SIP grammar doubt.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 01:59:26 -0500



 

> -----Original Message-----
> From: Vijeth D [mailto:vijethd@rediffmail.com]
> Sent: Thursday, January 04, 2001 7:33 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] SIP grammar doubt.
> 
> 
> Hi,
> 
>  I am referrring to draft-ietf-sip-rfc2543bis-01.abnf for the 
> sip message grammar. The authorization and the WWW Auth. 
> header fields have been specified as using PGP based 
> encryption.But RFC says that SIP can support both basic and 
> digest schemes of HTTP. 

The format of the headers is actually specified in rfc2616, which says:

Authorization  = "Authorization" ":" credentials

credentials is defined in rfc2617 for the case of Basic and Digest:

credentials      = "Digest" digest-response
digest-response  = 1#( username | realm | nonce | digest-uri
                       | response | [ algorithm ] | [cnonce] |
                       [opaque] | [message-qop] |
                           [nonce-count]  | [auth-param] )


credentials = "Basic" basic-credentials

and then the PGP version is defined in rfc2543bis:

Authorization = "Authorization" ":" "pgp" # pgp-response
pgp-response = realm | pgp-version | pgp-signature
               | signed-by | nonce



A generalization is that the structure of the header is:

Authorization = "Authorization" ":" mechanisms 1#mech-params
mechanisms = "pgp" | "Basic" | "Digest" | token
mech-params = digest-response | basic-response | pgp-response


Note, however, that we are going to deprecate PGP stuff. It will be
superceded by S/MIME and PGP MIME.

-Jonathan R.



---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 02:27:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07398
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 02:27:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EBC7444337; Tue,  9 Jan 2001 01:28:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id E98D544336
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 01:27:58 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA16435;
	Tue, 9 Jan 2001 02:30:06 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBY32>; Tue, 9 Jan 2001 02:24:23 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB01B@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Michael Thomas'" <mat@cisco.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Christian Huitema'" <huitema@exchange.microsoft.com>,
        Henning Schulzrinne <hgs@cs.columbia.edu>, sip@lists.bell-labs.com
Subject: RE: [SIP] new record-route text!
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 02:24:16 -0500



 

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Thursday, January 04, 2001 11:20 AM
> To: Jonathan Rosenberg
> Cc: 'Christian Huitema'; Henning Schulzrinne; sip@lists.bell-labs.com
> Subject: RE: [SIP] new record-route text!
> 
> 
> Jonathan Rosenberg writes:
>  > > From: Christian Huitema [mailto:huitema@exchange.microsoft.com]
>  > > I am concerned with the mandatory aspect of the record-route 
>  > > parameter.
>  > > Part of the beauty of SIP is that it can operate in a strict 
>  > > end-to-end
>  > > mode; the record-route procedure allows intermediaries 
> to arbitrarily
>  > > break that end-to-end property. I understand that this 
> could be useful
>  > > sometimes, for some crazy network configurations,
>  > 
>  > Er, I suspect these "crazy" cases are likely to be the 
> norm (i.e., presence
>  > of NATs and firewalls).
> 
> Jonathan,
> 
> I respect your desire to get this to play as well
> as to be expected with fog machines, but if it
> comes at the cost of making a mess out of a clear,
> sunny net I have serious problems. Assuming you
> haven't already drank the kool-aid, let's be
> careful here; record route is a sometimes useful,
> but unwieldy and unreliable tool which should be
> used as little as possible. The preface text of
> RR ought to be "If you think you need it, you
> probably don't. Think again."

I just don't agree with that. If thats the case, boy 
have we been wasting a lot of time specifying and testing
it at bakeoffs. 

Record route serves many useful functions; functions that
user agents will want to get from proxy servers. They are critical
for call features (such as those provided by sip cgi, cpl, servlets, etc.),
security functions of all sorts, including but not limited to firewall
traversal,
building distributed proxy systems (whereby pieces of a proxy or gateway
function reside in distributed proxies, rather than all in one), and so on. 

Record routing is the ultimate in flexibility. A proxy that doesn't need to
be in the call path can get out of the way, and one which needs to be in the
call path to serve a useful function, can. It allows people to build sip
networks of all different flavors, and have them work with the same UA.

If you make record-route support in a UA optional, the result is that things
which the user expects to work (call features, correct call establishment,
etc.) won't in some cases. I don't want to have to have our customer support
folks field calls like "I can't call California, ever", with an answer of,
"oh, well, your phone doesn't support record-route, and the california proxy
is performing some security checks that require you to route through it.
Sorry, and have a nice day". 

People also know that I'm a big fan of new applications enabled by sip. Fact
is, some of these applications live in servers in the network. Many of these
won't work if proxies can't see all signaling for the call. I'm afraid that
we will literally destroy sips ability to provide services if we don't
ensure that record route functions properly. I do not think the answer
should be "use a B2BUA for all of these". There is a big cost difference in
having a B2BUA process calls as compared to a proxy, and there are also
security issues that arise. B2BUA is applicable in some cases, to be
certain, but not in EVERY case where we want call state aware processing in
the network.

The burden of record-route support in UA is small. You need to store the
record-route list and reuse it for subsequent requests. Its not a big deal. 

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 02:38:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07471
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 02:38:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C4AEB44358; Tue,  9 Jan 2001 01:39:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 69EE444337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 01:38:04 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA16472;
	Tue, 9 Jan 2001 02:40:38 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFBY3R>; Tue, 9 Jan 2001 02:34:55 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB01D@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Rohan Mahy'" <rohan@cisco.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] REFER open issues
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C07A0E.A7B2E7D2"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 02:34:44 -0500

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_01C07A0E.A7B2E7D2
Content-Type: text/plain;
	charset="iso-8859-1"

I don't want to have an interim meeting JUST on REFER. There are lots of
other open issues. We should seek to accomplish as much as possible in one
meeting, rather than having meetings for each issue. 
 
-Jonathan R.
 

Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen <http://www.cs.columbia.edu/~jdrosen>
PHONE: (973) 952-5000
http://www.dynamicsoft.com <http://www.dynamicsoft.com/> 
  

-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Monday, January 08, 2001 11:20 AM
To: sip@lists.bell-labs.com
Subject: Re: [SIP] REFER open issues


Hi,

I've heard some mixed interest at the IETF, and no objections to an interim
meeting to build some consensus around REFER open issues.  If you are
intersted in attending a meeting **and have posted to the list on one of
these REFER-related topics**, please indicate your availability and ability
to travel to some sample US destinations the last week of January/first week
of February by filling in the grid below.  an [x] means you are available, a
[?] is a maybe.

Of course all the meeting minutes, proposals, etc will get posted back to
this list.
Again, please do not spam the whole list with your availability.  I'll post
a summary.

        Please use a fixed-width font such as Courier.

        Available    San Jose   Dallas   New York  RaleighNC  Other

Jan 29    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
    30    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
    31    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
Feb  1    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
     2    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]

     5    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
     6    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
     7    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
     8    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
     9    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]


thanks,
-rohan


At 10:08 AM 12/15/00 , Rohan Mahy wrote:
>Hi,
>
>I'd like to summarize ALL the open issues that we have with REFER.  In the
>interest of coming to consensus, I'd like to invite interested implementers
>who have comments to meet in person before Minneapolis to close REFER open
>issues.  If folks think this is a good idea, we would certainly post the
>minutes and partial consensus back to the list for comments/changes.  As a
>strawman, I will suggest sometime in the last week of January.  A few
>plausible locations are: Dallas, New York, San Jose...  I volunteer to
>organize this if necessary.
>
>A short summary of the issues are below in no particular order:
>
>1) Retransmission problem:
>Robert Sparks already summarized this problem in his recent post.
>(a) REFER completes early, use explicit SUBSCRIBE for more info
>(b) REFER completes early and implicitly SUBSCRIBEs to more info
>(c) REFER completes after 16 secs and provides URL for SUBSCRIBE
>(d) send new REFER (new CSeq same call ID) after 32 seconds.
>
>2) Cancellation:
>If REFER returns a final response before a long INVITE transaction
>completes, how do you cancel that INVITE?  
>(a) send same REFER with ;method=CANCEL
>(b) send REFERCANCEL method
>
>3) Call-leg matching:
>Should you include call-id's in Refer-to URLs?  If not, what do you use for
>matching (Replaces or similar)?
>(a) match call-ids
>(b) use a Replaces header
>(c) use the mesh-id to setup mesh, then say BYE
>(d) use a new header
>
>4) If we choose Replaces or the like, how do we express that we want to
>*join* 2 legs via REFER?
>(a) Join header
>(b) Associate header
>(c) new method
>(d) something else
>
>5) If Refer-To contains parameters (method, transport), or potentially
>contradictory headers, what do we do with them?
>(a) allow all of them if authorized
>(b) allow a subset of methods/headers
>(c) send an error mesage
>(d) ignore the headers/parameters
>(e) ignore the whole message
>
>6) If we don't allow  ;method=BYE, how do we solve the problem described in
>the Music on 
>Hold flow?
>(a) method=BYE
>(b) ???
>
>7) How do we ask devices to do stuff for us?  [probably defer this issue]
>(a) REFER with parameters/headers
>(b) PHONECTL
>(c) some NEWMETHOD
>(d) Mbus
>(e) other
>
>Any other REFER open issues I missed?
>
>thanks,
>-rohan
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip> 



------_=_NextPart_001_01C07A0E.A7B2E7D2
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D251493307-09012001><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2>I don't want to have an interim meeting JUST on REFER. There =
are lots of=20
other open issues. We should seek to accomplish as much as possible in =
one=20
meeting, rather than having meetings for each issue. =
</FONT></SPAN></DIV>
<DIV><SPAN class=3D251493307-09012001><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D251493307-09012001><FONT face=3D"Courier New" =
color=3D#0000ff=20
size=3D2>-Jonathan R.</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P><FONT size=3D2>Jonathan D.=20
Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
72 Eagle Rock Ave.<BR>Chief=20
Scientist&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
First=20
Floor<BR>dynamicsoft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
East Hanover, NJ=20
07936<BR>jdrosen@dynamicsoft.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
FAX:&nbsp;&nbsp; (973) 952-5050<BR><A target=3D_blank=20
href=3D"http://www.cs.columbia.edu/~jdrosen">http://www.cs.columbia.edu/=
~jdrosen</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
PHONE: (973) 952-5000<BR><A target=3D_blank=20
href=3D"http://www.dynamicsoft.com/">http://www.dynamicsoft.com</A><BR>&=
nbsp;</FONT>=20
</P>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Rohan Mahy=20
  [mailto:rohan@cisco.com]<BR><B>Sent:</B> Monday, January 08, 2001 =
11:20=20
  AM<BR><B>To:</B> sip@lists.bell-labs.com<BR><B>Subject:</B> Re: [SIP] =
REFER=20
  open issues<BR><BR></FONT></DIV>Hi,<BR><BR>I've heard some mixed =
interest at=20
  the IETF, and no objections to an interim meeting to build some =
consensus=20
  around REFER open issues.&nbsp; If you are intersted in attending a =
meeting=20
  **and have posted to the list on one of these REFER-related topics**, =
please=20
  indicate your availability and ability to travel to some sample US=20
  destinations the last week of January/first week of February by =
filling in the=20
  grid below.&nbsp; an [x] means you are available, a [?] is a =
maybe.<BR><BR>Of=20
  course all the meeting minutes, proposals, etc will get posted back =
to this=20
  list.<BR>Again, please do not spam the whole list with your=20
  availability.&nbsp; I'll post a summary.<BR><BR><FONT=20
  face=3D"Courier, Courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Please use=20
  a fixed-width font such as=20
  Courier.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Available&nbsp;&nbsp;&nbsp; San Jose&nbsp;&nbsp; Dallas&nbsp;&nbsp; =
New=20
  York&nbsp; RaleighNC&nbsp; Other<BR><BR>Jan 29&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  [ ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]<BR>&nbsp;&nbsp;&nbsp; 30&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  [ ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ ]&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; [=20
  ]<BR>&nbsp;&nbsp;&nbsp; 31&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  [ ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]<BR>Feb&nbsp; 1&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  [ ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]<BR>&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  [ ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  [ ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]<BR>&nbsp;&nbsp;&nbsp;&nbsp; 6&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  [ ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]<BR>&nbsp;&nbsp;&nbsp;&nbsp; 7&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  [ ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]<BR>&nbsp;&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  [ ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]<BR>&nbsp;&nbsp;&nbsp;&nbsp; 9&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  [ ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
  ]<BR><BR><BR></FONT>thanks,<BR>-rohan<BR><BR><BR>At 10:08 AM 12/15/00 =
, Rohan=20
  Mahy wrote:<BR>&gt;Hi,<BR>&gt;<BR>&gt;I'd like to summarize ALL the =
open=20
  issues that we have with REFER.&nbsp; In the<BR>&gt;interest of =
coming to=20
  consensus, I'd like to invite interested implementers<BR>&gt;who have =
comments=20
  to meet in person before Minneapolis to close REFER =
open<BR>&gt;issues.&nbsp;=20
  If folks think this is a good idea, we would certainly post =
the<BR>&gt;minutes=20
  and partial consensus back to the list for comments/changes.&nbsp; As =

  a<BR>&gt;strawman, I will suggest sometime in the last week of =
January.&nbsp;=20
  A few<BR>&gt;plausible locations are: Dallas, New York, San =
Jose...&nbsp; I=20
  volunteer to<BR>&gt;organize this if necessary.<BR>&gt;<BR>&gt;A =
short summary=20
  of the issues are below in no particular order:<BR>&gt;<BR>&gt;1)=20
  Retransmission problem:<BR>&gt;Robert Sparks already summarized this =
problem=20
  in his recent post.<BR>&gt;(a) REFER completes early, use explicit =
SUBSCRIBE=20
  for more info<BR>&gt;(b) REFER completes early and implicitly =
SUBSCRIBEs to=20
  more info<BR>&gt;(c) REFER completes after 16 secs and provides URL =
for=20
  SUBSCRIBE<BR>&gt;(d) send new REFER (new CSeq same call ID) after 32=20
  seconds.<BR>&gt;<BR>&gt;2) Cancellation:<BR>&gt;If REFER returns a =
final=20
  response before a long INVITE transaction<BR>&gt;completes, how do =
you cancel=20
  that INVITE?&nbsp; <BR>&gt;(a) send same REFER with =
;method=3DCANCEL<BR>&gt;(b)=20
  send REFERCANCEL method<BR>&gt;<BR>&gt;3) Call-leg =
matching:<BR>&gt;Should you=20
  include call-id's in Refer-to URLs?&nbsp; If not, what do you use=20
  for<BR>&gt;matching (Replaces or similar)?<BR>&gt;(a) match=20
  call-ids<BR>&gt;(b) use a Replaces header<BR>&gt;(c) use the mesh-id =
to setup=20
  mesh, then say BYE<BR>&gt;(d) use a new header<BR>&gt;<BR>&gt;4) If =
we choose=20
  Replaces or the like, how do we express that we want to<BR>&gt;*join* =
2 legs=20
  via REFER?<BR>&gt;(a) Join header<BR>&gt;(b) Associate =
header<BR>&gt;(c) new=20
  method<BR>&gt;(d) something else<BR>&gt;<BR>&gt;5) If Refer-To =
contains=20
  parameters (method, transport), or potentially<BR>&gt;contradictory =
headers,=20
  what do we do with them?<BR>&gt;(a) allow all of them if =
authorized<BR>&gt;(b)=20
  allow a subset of methods/headers<BR>&gt;(c) send an error =
mesage<BR>&gt;(d)=20
  ignore the headers/parameters<BR>&gt;(e) ignore the whole=20
  message<BR>&gt;<BR>&gt;6) If we don't allow&nbsp; ;method=3DBYE, how =
do we solve=20
  the problem described in<BR>&gt;the Music on <BR>&gt;Hold =
flow?<BR>&gt;(a)=20
  method=3DBYE<BR>&gt;(b) ???<BR>&gt;<BR>&gt;7) How do we ask devices =
to do stuff=20
  for us?&nbsp; [probably defer this issue]<BR>&gt;(a) REFER with=20
  parameters/headers<BR>&gt;(b) PHONECTL<BR>&gt;(c) some =
NEWMETHOD<BR>&gt;(d)=20
  Mbus<BR>&gt;(e) other<BR>&gt;<BR>&gt;Any other REFER open issues I=20
  =
missed?<BR>&gt;<BR>&gt;thanks,<BR>&gt;-rohan<BR>&gt;<BR>&gt;<BR>&gt;<BR>=
&gt;_______________________________________________<BR>&gt;SIP=20
  mailing list<BR>&gt;SIP@lists.bell-labs.com<BR>&gt;<A=20
  href=3D"http://lists.bell-labs.com/mailman/listinfo/sip"=20
  =
eudora=3D"autourl">http://lists.bell-labs.com/mailman/listinfo/sip</A><B=
R></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C07A0E.A7B2E7D2--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 02:41:43 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07505
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 02:41:43 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8D98644366; Tue,  9 Jan 2001 01:39:10 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id 92F6F44337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 01:38:13 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f097baG04281;
	Tue, 9 Jan 2001 08:37:37 +0100 (MET)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.40])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA00905;
	Tue, 9 Jan 2001 09:37:36 +0200 (EET)
Message-ID: <3A5ABF93.A3ADB7E7@lmf.ericsson.se>
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Cc: Keith Robinson <Keith.Robinson@marconi.com>, Steve Levy <stlevy@cisco.com>
Subject: Re: [SIP] Overlap Sending
References: <802569CE.005CD879.00@marconicomms.com>
Content-Type: multipart/mixed;
 boundary="------------97DBAEF767539A1D48595BAD"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 09:36:51 +0200

This is a multi-part message in MIME format.
--------------97DBAEF767539A1D48595BAD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

>>"I don't know. I haven't seen a proxy that would route depending on the
>>user, but it COULD happend. Let's assume , for example, that you do a
>>SRV DNS lookup, and get a list of servers. Then you MAY choose a
>>different server, for load balance purpose e.g., depending on the user
>>name. Just an example..."
> 
>One way of ensuring that subsequent requests always traverse a given SIP
>node is for that node to Record-Route or supply a Contact ; it is likely 
>that proxies and UAS at PSTN interworking points will require to stay in 
>the signalling path during call setup so will do so.  Now, suppose one 
>such node receives an initial INVITE with a R-URI of sip:654@sipgw.com 
>and creates a Contact header thus:
> 
> Contact: sip:654@sipgw.com;maddr=sipgw.com

Let's assume that the first proxy (P1) receives the R-URI
sip:654@sipgw.com and forwards it
to P2, which insert itself in the route and returns 484. The client then
sends 654123@sipgw.com, which goes via P1 to P2. P2 then forwards it
somewhere else etc., until it reaches the final UAS.

However, if the client would have sent 65412@sip.gw in the initial
INVITE, P1 would maybe have forwarded it to P3 instead of P2, which
means that the subsequent 654123@sipgw.com will take another route. This
may not be a problem, but again - you MAY want to send a specific number
via a specific proxy (for load balance/billing/monitoring/whatever
reason) - no matter if how the number is divided between INVITE
messages.

Again, this could be solved if you are able to configure the proxies.
And, if you don't own the proxies you could send some kind of digit map
header, telling the proxy to forward any matching number to the same
place (e.g. P2). 

Then:

INVITE 654@sipgw.com
Forward-digit-map: 65xxxx

...would be treated, and forwarded by proxies, exactly like...

INVITE 654123@sipgw.com
Forward-digit-map: 65xxxx


A possible problem with this approach, though, is that the UAC would
tell the proxy what to do, but that is possible using the SIP Caller
Prefs anyway, so...

Just an idea...
 
>This is then returned in the 484 response so that the sending UA may 
>build a Route header from it. Here is my first concern; will the sending 
>UA treat the subsequent INVITE as a subsequent INVITE or as a new INVITE 
>on a new Call-Id ? I ask because the 484 response is non-200 final 
>response which implies that that call attempt has failed; obviously in 
>this case it hasn't failed (not yet, anyway) its just been partially set 
>up. Does this lead to special case handling for a particular 4XX response 
>? In fact, the 484 is almost like an informational response.
>Would it be better to send an informational response (say 183) and the 
>spec updated to allow subsequent INVITEs to be sent before the final ACK 
>(a point raised by J. Rosenberg earlier on the list, but in a different 
>context - to convey updated SDP information).

Allowing subsequent INVITEs before a final answer would also solve some
ISUP transparency issues. However, allowing it would probably - again -
produce lots of problematic cases (again, especially in a SIP/PSTN GW
scenario) and what-ifs, so IF it is to be allowed it should be very
cleary defined HOW and in WHAT FOR.

>Assuming the above is resolved one way or another, then a SIP node 
>preceding sipgw.com is going to receive a subsequent INVITE for this call 
>(containing additional digits 321)  that will look something like:
> 
>INVITE sip:321@preceding.sipgw.com
>Route: sip:654@sipgw.com;maddr=sipgw.com
> 
>As a Route header is present, this will be used to route the INVITE so
>therefore sipgw.com will receive an INVITE with the following Request
>Line:
> 
>INVITE sip:654@sipgw.com;maddr=sipgw.com
> 
>And here is a more worrying problem, the subsequent digits have been lost.
>The situation would be no better if the subsequent INVITE contained original
>digits plus subsequent digits; they would still be lost.
> 
>The problem stems from the fact that the R-URI is supposed to be invariant at
>each node during the lifetime of the call leg, yet to do overlap sending it is being
>used to convey new information so therefore does not remain invariant and other parts of
>the protocol which assume it is invariant e.g., routing using the Route header
>break.
>Using a TEL URL does not help either; the digits would still be lost >after the popping of the Route entry >into the R-URI.

Personally I don't see ANY case where TEL URL would help with ANYTHING
in a SIP network... :) It will just produce extra DNS lookup traffic.
 
>It would be easier to implement overlap sending if a seperate header 
>could be used to convey the dialled digits, so an original INVITE may >look something like:
> 
>INVITE sip:digitdecode@sipgw.com
>Current-Dial-String: 01623
> 
>The subsequent INVITES would then look something like:
> 
>INVITE sip:digitdecode@sipgw.com;maddr=sipgw.com
>Current-Dial-String: 01623654398

Won't the To header show the current dial string, because it will not be
changed by proxies?

i.e.

INVITE sip:digitdecode@sipgw.com;maddr=sipgw.com
To: 01623@uas.com

...and the subsequent request...

INVITE sip:digitdecode@sipgw.com;maddr=sipgw.com
To: 01623654398@uas.com
 
>This ties in with your point of implementing a digit map header.
> 
>Regards,
> 
>K. Robinson.


Regards,

Christer Holmberg
Ericsson Finland



> Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 3:40:47
> 
> 
> 
> 
> 
> 
> 
>  To:      sip@lists.bell-labs.com
> 
>  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
>           <stlevy@cisco.com>
> 
> 
> 
>  Subject: Re: [SIP] Overlap Sending
> 
> 
> Hi,
> 
> >If a proxy, not serving uas.com, receives an INVITE with a R-URI of 4@uas.com,
> >why would it route it differently (Route headers not withstanding) from an
> INVITE
> >with a R-URI of 441@uas.com ?
> 
> I don't know. I haven't seen a proxy that would route depending on the
> user, but it COULD happend. Let's assume , for example, that you do a
> SRV DNS lookup, and get a list of servers. Then you MAY choose a
> different server, for load balance purpose e.g., depending on the user
> name. Just an example...
> 
> And, what happen if you use a TEL-URL, where you have to route depending
> on the user name (=telephone number). I guess using a ENUM DNS lookup
> COULD route it to the same host, but then I guess you would have to
> configure your DNS to for all the possible combinations (4.e164.arpa,
> 44.e164.arpa and 441.e164.arpa)...
> 
> >Surely, if the proxy does not serve the domain identified in the R-URI it
> cannot
> >make any routing decisions based on the user part of the R-URI.
> >If, on the other hand, the proxy does serve uas.com, then it will be involved
> in
> >routing the call using the dialled digit string and I would expect it to know
> such things as minimum digits to
> >translation and perhaps even maximum number of digits to follow. Also, because
> the proxy is doing digit based
> >routing it must be subject to the requirements of overlap sending so I would
> expect it to be stateful, at >least until call setup is complete, in which case
> remembering previous call information would be reasonable. >In fact, such a
> proxy appears much like the interworking UAs I referred to previously and to
> which my question >applies.
> 
> That was my point - that you also have to have support for this in your
> proxies, and not only in your client.
> 
> I think the issue is that there are lots of what-ifs involved in this,
> and it should be specified how the specific cases are handled -
> especially by proxies and redirect servers.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> > Regards,
> >
> > K. Robinson
> >
> > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
> >
> >
> >
> >
> >
> >
> >
> 
> Keith Robinson wrote:
> >
> > If a proxy, not serving uas.com, receives an INVITE with a R-URI of 4@uas.com,
> > why
> > would it route it differently (Route headers not withstanding) from an INVITE
> > with a R-URI of 441@uas.com ?
> > Surely, if the proxy does not serve the domain identified in the R-URI it
> cannot
> > make any
> > routing decisions based on the user part of the R-URI.
> >
> > If, on the other hand, the proxy does serve uas.com, then it will be involved
> in
> > routing the call using the dialled
> > digit string and I would expect it to know such things as minimum digits to
> > translation and perhaps even
> > maximum number of digits to follow. Also, because the proxy is doing digit
> based
> > routing it must be subject to the
> > requirements of overlap sending so I would expect it to be stateful, at least
> > until call setup is complete, in which
> > case remembering previous call information would be reasonable. In fact, such
> a
> > proxy appears much like the
> > interworking UAs I referred to previously and to which my question applies.
> >
> > Regards,
> >
> > K. Robinson
> >
> > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
> >
> >
> >
> >
> >
> >
> >
> >  To:      sip@lists.bell-labs.com
> >
> >  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
> >           <stlevy@cisco.com>
> >
> >
> >
> >  Subject: Re: [SIP] Overlap Sending
> >
> >
> > Hi,
> >
> > I think sending re-INVITES containing only subsequent digits will create
> > some problems. It's not enough that the UAS remembers the previous
> > INVITEs for the specific Call-ID, you may also have intermediate
> > redirect- and/or proxy servers that make their redirect/forwarding
> > decissions based on the destination number, and then they would also
> > have to remember the previous INVITEs, and they would possible also have
> > to be able to know if, and in some cases, how many digits will follow
> > (e.g. 4@uas.com may be routed to a complete destination than
> > 441@uas.com, etc.) Maybe we should implement some kind of digit-map
> > header, or something... :)
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> > Keith Robinson wrote:
> > >
> > > Yes, this is the type of case I have in mind. The question I have is what
> are
> > > the subsequent INVITES; are they
> > >
> > > a) New INVITES, on a new Call-Id containing the original digits (from
> original
> > > INVITE) + subsequent digits ?
> > >
> > > or
> > >
> > > b) re-INVITES containing only subsequent digits ?
> > >
> > > or
> > >
> > > c) re-INVITES containing original digits + subsequent digits ?
> > >
> > > The sending UAs I referred to in my previous note are those that sit in
> > PSTN/SIP
> > > gateways,
> > > not necessarily an originating UA sitting on someones desktop.
> > >
> > > So, the question applies as much to these interworking UAs for constructing
> > > the subsequent INVITEs as well as to receiving UAs for interpreting them.
> > >
> > > Regards,
> > >
> > > K. Robinson.
> > >
> > > Steve Levy <stlevy@cisco.com> on 05/01/2001 22:32:00
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  To:      Keith Robinson/MAIN/MC1@MCMAIN,
> > >           sip@lists.bell-labs.com
> > >
> > >  cc:
> > >
> > >
> > >
> > >  Subject: Re: [SIP] Overlap Sending
> > >
> > >
> > > Hi Keith,
> > >
> > > I was wondering if in considering overlap sending issues and SIP if you were
> > > considering the case of overlap sending across multiple networks with
> variable
> > > length digits.
> > >
> > > In this case, in order to avoid post dial delay, the digits need to be
> passed
> > > through the networks to the final destiantion network prior to end of dial
> > > (since the destination network is the only network that knows how many
> digits
> > > are required). So in effect there may be additional digits sent after an
> > INVITE
> > > has been received and sent downstream to the callee.
> > >
> > > Thanks,
> > > Steve
> > >
> > > At 03:50 PM 1/5/01 +0000, Keith Robinson wrote:
> > > >
> > > >
> > > >I have the following query regarding overlap sending as defined in
> > > >rfc2543bis-02:
> > > >
> > > >Section 4.2.1 states the following:
> > > >
> > > >"...the UAS compares the Request-URI with Request-URI of the previous
> INVITE
> > > >request
> > > >for the same Call-Id. If the Request-URI  contains additional digits in the
> > > >'user' part, the UAS
> > > >treats the INVITE as adding additional digits to the original dialed
> string."
> > > >
> > > >This appears to imply that the subsequent INVITE contains the original
> > dialled
> > > >string plus the
> > > >additional digits; if this is the case, then there is no need for the UAS
> to
> > > >remember the
> > > >previous string, and therefore no need to keep any state regarding the
> > previous
> > > >attempt.
> > > >The subsequent INVITE can really be a new INVITE., i.e. a new Call-Id.
> > > >
> > > >If, on the other hand, the sending UA only sends additional digits, then
> the
> > > >original digits
> > > >will have to be remembered by the UAS, and the INVITE matched up with this
> > > >state
> > > >so
> > > >this INVITE must be on the same Call-Id.
> > > >
> > > >This latter case is similar to the way existing telephony protocols
> transmit
> > > >addtional digits
> > > >when doing overlap sending.
> > > >
> > > >So, upon receiving a response of 484 Address Incomplete, does the sending
> UA
> > > >send
> > > >original digits plus aditional digits on a new Call-Id or additional digits
> > > >only
> > > >on the same
> > > >Call-Id with an incremented Cseq.
> > > >
> > > >Regards,
> > > >
> > > >K. Robinson.
> > > >
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >SIP mailing list
> > > >SIP@lists.bell-labs.com
> > > >http://lists.bell-labs.com/mailman/listinfo/sip
> > >
> > > _______________________________________________
> > > SIP mailing list
> > > SIP@lists.bell-labs.com
> > > http://lists.bell-labs.com/mailman/listinfo/sip
> > >
> > > _______________________________________________
> > > SIP mailing list
> > > SIP@lists.bell-labs.com
> > > http://lists.bell-labs.com/mailman/listinfo/sip
--------------97DBAEF767539A1D48595BAD
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------97DBAEF767539A1D48595BAD--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 02:51:13 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07533
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 02:51:12 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C17C744372; Tue,  9 Jan 2001 01:45:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id CEF8344369
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 01:44:33 -0500 (EST)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <CKD5PVVM>; Mon, 8 Jan 2001 23:44:27 -0800
Message-ID: <E79883AEA37FD411A58C00508BAC5F4B2B5C30@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Early media replacement.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C07A0F.F9E079B0"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 23:44:20 -0800

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_01C07A0F.F9E079B0
Content-Type: text/plain;
	charset="iso-8859-1"

> > 
> > If we keep early media, then we need to keep 
> > the 183 cruft, otherwise parallel forking proxies
> > can't know they have forked to two simultaneous
> > streaming media locations, a no-no. 
> 
> In practice, I doubt calls to PSTN numbers will fork anyway. 
> That aside, a UA can deal with the multiplicity of streams in the
> standard RTP way - sort them out by SSRC, and play one and/or mix
> them as it sees fit. It needs to be able to do that whether or not
> the 183 message is present. 

I'm not sure about this. I imagine a common forking cases would a simple
"helpdesk" style attendant pool. Where one helpdesk INVITE request is forked
to a pool of attendents/extensions and the first to answer is connected. An
attendent may have either registered a PSTN/PBX extension to the proxy or
they may have forwarded their SIP phone to a PSTN number (mobile phone?) at
their local proxy. In this case, the proxy will either not know about the
PSTN endpoint or will not be able to do anything about it (ie, must still
fork).

> 
> I am unwilling to dismiss PSTN interoperability as 
> an important issue for SIP. My hope is to allow a 
> normal SIP UA phone or PC client to not have to
> worry too much about it. The proposed solution
> of receiving media after INVITE (with the caveat that
> your RTP implementation needs to be correct and sort
> by SSRC any media that comes), alleviates any complex
> work on the side of a UA, and still pretty much
> works.
> 

And from Rick Dean's reply:

> 
> If we keep early media, then we need to keep 
> the 183 cruft, otherwise parallel forking proxies
> can't know they have forked to two simultaneous
> streaming media locations, a no-no.  Never mind 
> the UAC problems and possible non-support for mixing;
> mixed ringbacks (even without busy & errors) 
> do not make sense to end users.  My limited 
> focus group testing is resoundingly negative.  
> They hang up.

How about switching back to local ringback whenever you receive provisional
responses from multiple UAS's? It may sound just a little bit strange but it
should not cause a user to hangup because they will probably be used to hear
this type of behaviour in existing PSTN system (for example, changes in
ringtone due to call forwarding). [I agree that mixing early media streams
is probably doomed to failure.]

As far as I can see there are three four cases:
1)PSTN gateway wants to provide remote/personalized ringback stream (or
other queued, etc non-terminal announcement). 
In this case the gateway should send the appropriate event code (180, 181,
182, etc) with SDP. One way media is end forced on both sides. This case is
when the gateway knows that the user is being alerted. It may also be issued
subsequent to 183 or other provisional responses. 
2)PSTN gateway understands that a terminal event occurred. It should send
appropriate final 300+ response without any media stream. For instance, if
the gateway knows that the stream is saying "The number has been
disconnected" it should not try to stream this message in a provisional
response. The message may even be spoken in a foreign language. For
PSTN-SIP-PSTN networks, the caller's PSTN gateway should be responsible for
regenerating a "disconnected" message in the subscribers native language.
3)PSTN gateway does not understand meaning of media stream (it could be
maybe transient ringback/announcements or it could be "terminal" call
progress events). 
The gateway has no choice but to send a 183 Session Prgress response with
SDP (and then a 4xx when the PSTN side times out). This is the least
damaging for request forking (in my mind). Returning a 200OK and playign the
"This number has been disconnected" announcement has the same effect as
returning a 6xx response, that is, it cancels all other branches which is
not appropriate as user intervention isn't possible. (IMO)
4)PSTN gateway requires interaction before the connection is established. 
In this case, the call is effectively being answered by an automated agent
and should be treated as such, that is, a 200 OK is sent and a two-way
session is set up so that DTMF digits or verbal authentication/directions
can be relayed. In this case it would be useful to have some indication to
which entity the session is currently connected "the agent" or "the user". I
don't think the effects on request forking is a large concern with this
style of session interaction.

If a PSTN call is forked and local ringback is forced (as suggested above),
the session progress announcements are lost. Is this such a big problem? If
it the request is forked then the system is probably less concerned if one
branch of the search path has "problems" (hence forking in the first place).


I still think that it would be nice to have a SIP Header that describes the
general characteristics of the entity currently "connected" to the session.
Eg PSTN Gateway, Automated Agent or Human? This information may allow user
agents and proxies to make informed decisions about "what the hell to do!"
or it could be used for billing (in the fourth case). Eg, if proxy or UA
receives a 100 Trying with a SIP header says that the call is being
processed by a PSTN gateway then it may take special action. Likewise the
200 OK could tell you whether the call is beign answered by a person or an
automated agent (and subsequently when the user is finally connected).

Comments?

Robert.

-- My opinions are my own and should not be taken as representing those
of Nuera Communications, Inc. -- 


------_=_NextPart_001_01C07A0F.F9E079B0
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [SIP] Early media replacement.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; If we keep early media, then we need to =
keep </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the 183 cruft, otherwise parallel forking =
proxies</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; can't know they have forked to two =
simultaneous</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; streaming media locations, a no-no. =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In practice, I doubt calls to PSTN numbers will =
fork anyway. </FONT>
<BR><FONT SIZE=3D2>&gt; That aside, a UA can deal with the multiplicity =
of streams in the</FONT>
<BR><FONT SIZE=3D2>&gt; standard RTP way - sort them out by SSRC, and =
play one and/or mix</FONT>
<BR><FONT SIZE=3D2>&gt; them as it sees fit. It needs to be able to do =
that whether or not</FONT>
<BR><FONT SIZE=3D2>&gt; the 183 message is present. </FONT>
</P>

<P><FONT SIZE=3D2>I'm not sure about this. I imagine a common forking =
cases would a simple &quot;helpdesk&quot; style attendant pool. Where =
one helpdesk INVITE request is forked to a pool of =
attendents/extensions and the first to answer is connected. An =
attendent may have either registered a PSTN/PBX extension to the proxy =
or they may have forwarded their SIP phone to a PSTN number (mobile =
phone?) at their local proxy. In this case, the proxy will either not =
know about the PSTN endpoint or will not be able to do anything about =
it (ie, must still fork).</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I am unwilling to dismiss PSTN interoperability =
as </FONT>
<BR><FONT SIZE=3D2>&gt; an important issue for SIP. My hope is to allow =
a </FONT>
<BR><FONT SIZE=3D2>&gt; normal SIP UA phone or PC client to not have =
to</FONT>
<BR><FONT SIZE=3D2>&gt; worry too much about it. The proposed =
solution</FONT>
<BR><FONT SIZE=3D2>&gt; of receiving media after INVITE (with the =
caveat that</FONT>
<BR><FONT SIZE=3D2>&gt; your RTP implementation needs to be correct and =
sort</FONT>
<BR><FONT SIZE=3D2>&gt; by SSRC any media that comes), alleviates any =
complex</FONT>
<BR><FONT SIZE=3D2>&gt; work on the side of a UA, and still pretty =
much</FONT>
<BR><FONT SIZE=3D2>&gt; works.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>And from Rick Dean's reply:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If we keep early media, then we need to keep =
</FONT>
<BR><FONT SIZE=3D2>&gt; the 183 cruft, otherwise parallel forking =
proxies</FONT>
<BR><FONT SIZE=3D2>&gt; can't know they have forked to two =
simultaneous</FONT>
<BR><FONT SIZE=3D2>&gt; streaming media locations, a no-no.&nbsp; Never =
mind </FONT>
<BR><FONT SIZE=3D2>&gt; the UAC problems and possible non-support for =
mixing;</FONT>
<BR><FONT SIZE=3D2>&gt; mixed ringbacks (even without busy &amp; =
errors) </FONT>
<BR><FONT SIZE=3D2>&gt; do not make sense to end users.&nbsp; My =
limited </FONT>
<BR><FONT SIZE=3D2>&gt; focus group testing is resoundingly =
negative.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; They hang up.</FONT>
</P>

<P><FONT SIZE=3D2>How about switching back to local ringback whenever =
you receive provisional responses from multiple UAS's? It may sound =
just a little bit strange but it should not cause a user to hangup =
because they will probably be used to hear this type of behaviour in =
existing PSTN system (for example, changes in ringtone due to call =
forwarding). [I agree that mixing early media streams is probably =
doomed to failure.]</FONT></P>

<P><FONT SIZE=3D2>As far as I can see there are three four =
cases:</FONT>
<BR><FONT SIZE=3D2>1)PSTN gateway wants to provide remote/personalized =
ringback stream (or other queued, etc non-terminal announcement). =
</FONT>
<BR><FONT SIZE=3D2>In this case the gateway should send the appropriate =
event code (180, 181, 182, etc) with SDP. One way media is end forced =
on both sides. This case is when the gateway knows that the user is =
being alerted. It may also be issued subsequent to 183 or other =
provisional responses. </FONT></P>

<P><FONT SIZE=3D2>2)PSTN gateway understands that a terminal event =
occurred. It should send appropriate final 300+ response without any =
media stream. For instance, if the gateway knows that the stream is =
saying &quot;The number has been disconnected&quot; it should not try =
to stream this message in a provisional response. The message may even =
be spoken in a foreign language. For PSTN-SIP-PSTN networks, the =
caller's PSTN gateway should be responsible for regenerating a =
&quot;disconnected&quot; message in the subscribers native =
language.</FONT></P>

<P><FONT SIZE=3D2>3)PSTN gateway does not understand meaning of media =
stream (it could be maybe transient ringback/announcements or it could =
be &quot;terminal&quot; call progress events). </FONT></P>

<P><FONT SIZE=3D2>The gateway has no choice but to send a 183 Session =
Prgress response with SDP (and then a 4xx when the PSTN side times =
out). This is the least damaging for request forking (in my mind). =
Returning a 200OK and playign the &quot;This number has been =
disconnected&quot; announcement has the same effect as returning a 6xx =
response, that is, it cancels all other branches which is&nbsp; not =
appropriate as user intervention isn't possible. (IMO)</FONT></P>

<P><FONT SIZE=3D2>4)PSTN gateway requires interaction before the =
connection is established. </FONT>
<BR><FONT SIZE=3D2>In this case, the call is effectively being answered =
by an automated agent and should be treated as such, that is, a 200 OK =
is sent and a two-way session is set up so that DTMF digits or verbal =
authentication/directions can be relayed. In this case it would be =
useful to have some indication to which entity the session is currently =
connected &quot;the agent&quot; or &quot;the user&quot;. I don't think =
the effects on request forking is a large concern with this style of =
session interaction.</FONT></P>

<P><FONT SIZE=3D2>If a PSTN call is forked and local ringback is forced =
(as suggested above), the session progress announcements are lost. Is =
this such a big problem? If it the request is forked then the system is =
probably less concerned if one branch of the search path has =
&quot;problems&quot; (hence forking in the first place). </FONT></P>

<P><FONT SIZE=3D2>I still think that it would be nice to have a SIP =
Header that describes the general characteristics of the entity =
currently &quot;connected&quot; to the session. Eg PSTN Gateway, =
Automated Agent or Human? This information may allow user agents and =
proxies to make informed decisions about &quot;what the hell to =
do!&quot; or it could be used for billing (in the fourth case). Eg, if =
proxy or UA receives a 100 Trying with a SIP header says that the call =
is being processed by a PSTN gateway then it may take special action. =
Likewise the 200 OK could tell you whether the call is beign answered =
by a person or an automated agent (and subsequently when the user is =
finally connected).</FONT></P>

<P><FONT SIZE=3D2>Comments?</FONT>
</P>

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

<P><FONT SIZE=3D2>-- My opinions are my own and should not be taken as =
representing those</FONT>
<BR><FONT SIZE=3D2>of Nuera Communications, Inc. -- </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07A0F.F9E079B0--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 03:13:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07630
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 03:13:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BE9EB44337; Tue,  9 Jan 2001 02:14:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lists.bell-labs.com (Postfix) with ESMTP id 6DD3B44336
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 02:13:17 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f098Cu420856;
	Tue, 9 Jan 2001 09:12:56 +0100 (MET)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.40])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id KAA03060;
	Tue, 9 Jan 2001 10:12:54 +0200 (EET)
Message-ID: <3A5AC7D6.58769998@lmf.ericsson.se>
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'Rick Dean'" <siplist@fdd.com>
Subject: Re: [SIP] Early media replacement.
References: <B65B4F8437968F488A01A940B21982BF9AB016@DYN-EXCH-001.dynamicsoft.com>
Content-Type: multipart/mixed;
 boundary="------------148C6FAC0D77EE84003B6E70"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 10:12:06 +0200

This is a multi-part message in MIME format.
--------------148C6FAC0D77EE84003B6E70
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

A few comments on this thread.

First, a comment on the "media mixing". If you receive multiple 183
responses, with different SDPs, and from different locations - how do
you know if you shall mix all the media streams or if you shall replace
the first media stream with the other when the second 183 is received?  

And, PSTN numbers may not fork, but SIP numbers from a PSTN/SIP GW may
fork, so...

About replacing 183 with 200. Personally I don't think that is a good
idea - 183 is one for one purpose and 200 for another purpose. It does
allow us , among other things, to open a 2-way-communication when the
183 is received, but the billing would start at 200, etc.

I wouldn't mind having "provisional final responses" (which must be
ACKed), though. That will not solve this problem, but at least we
wouldn't have to play around with PRACK just to make sure we get the 183
(or any other provisional response) in the first place... :)

Regards,

Christer Holmberg
Ericsson Finland





Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Rick Dean [mailto:siplist@fdd.com]
> > Sent: Monday, January 08, 2001 8:01 PM
> > To: sip@lists.bell-labs.com
> > Subject: Re: [SIP] Early media replacement.
> >
> >
> >
> > If we keep early media, then we need to keep
> > the 183 cruft, otherwise parallel forking proxies
> > can't know they have forked to two simultaneous
> > streaming media locations, a no-no.
> 
> In practice, I doubt calls to PSTN numbers will fork anyway.
> That aside, a UA can deal with the multiplicity of streams in the
> standard RTP way - sort them out by SSRC, and play one and/or mix
> them as it sees fit. It needs to be able to do that whether or not
> the 183 message is present.
> 
> > Early media doesn't help.  Let's kill it.
> 
> I'm afraid that this will simply not fly.
> Gateways will, far too often, need to send
> media in the reverse direction without knowing
> what it is. The reality is that forking will be
> problematic for PSTN interworking.
> Thats a reality of PSTN interoperability.
> Whining about it will not cause the problem to go
> away.
> 
> I am unwilling to dismiss PSTN interoperability as
> an important issue for SIP. My hope is to allow a
> normal SIP UA phone or PC client to not have to
> worry too much about it. The proposed solution
> of receiving media after INVITE (with the caveat that
> your RTP implementation needs to be correct and sort
> by SSRC any media that comes), alleviates any complex
> work on the side of a UA, and still pretty much
> works.
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
--------------148C6FAC0D77EE84003B6E70
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------148C6FAC0D77EE84003B6E70--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 03:56:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07855
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 03:56:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BA9FF44337; Tue,  9 Jan 2001 02:57:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from nwcst277.netaddress.usa.net (nwcst277.netaddress.usa.net [204.68.23.22])
	by lists.bell-labs.com (Postfix) with SMTP id E4C5A44336
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 02:56:39 -0500 (EST)
Received: (qmail 28212 invoked by uid 60001); 9 Jan 2001 08:56:22 -0000
Message-ID: <20010109085622.28211.qmail@nwcst277.netaddress.usa.net>
Received: from 204.68.23.22 by nwcst277 for [203.197.178.200] via web-mailer(34FM.0700.15.02) on Tue Jan  9 08:56:22 GMT 2001
From: Nishith Chudasama <nishith76@usa.net>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "Nishith Chudasama" <nishith76@usa.net>,
        Vijay Gurbani <vkg@lucent.com>
Subject: Re: [RE: [Re: [SIP] REGISTRAR functions.]]
Cc: sip@lists.bell-labs.com
X-Mailer: USANET web-mailer (34FM.0700.15.02)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 9 Jan 2001 01:56:22 MST
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA07855

I am familiar abt SIP RFC but there is very little info regarding my queries
in the SIP RFC. Can you suggest me any other draft or document for my
queries?

> -----Original Message-----
> From: Nishith Chudasama [mailto:nishith76@usa.net]
> Sent: Monday, January 08, 2001 11:59 PM
> To: Vijay Gurbani; Nishith Chudasama
> Cc: sip@lists.bell-labs.com
> Subject: Re: [Re: [SIP] REGISTRAR functions.]
> 
> 
> RFC 2453 is for RIP. I couldn't find anything related to 
> REGISTRAR or REGISTER
> related to SIP.
> Kindly let me know if it was a typing mistake.

Its RFC2543. 

One can also find things easily on the web by using search engines. Typing
"sip" into www.google.com, for example, yields as the first result:

http://www.cs.columbia.edu/sip/

which has some tutorials, FAQs, links to standards, and so on. 

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com


____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 04:09:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07909
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 04:09:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id ED5424436B; Tue,  9 Jan 2001 03:10:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id 8F41E44369
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 03:09:30 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 9 Jan 2001 09:09:19 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id JAA06247; Tue, 9 Jan 2001 09:02:45 GMT
Message-ID: <3A5AD3B5.8A3EC4C5@ubiquity.net>
From: James Undery <jundery@ubiquity.net>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Deepak Mohan'" <deepakwarrier@rediffmail.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] "method" parameter in "contact"
References: <B65B4F8437968F488A01A940B21982BF9AB019@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 09:02:45 +0000
Content-Transfer-Encoding: 7bit



Jonathan Rosenberg wrote:

>
>
> > -----Original Message-----
> > From: Deepak Mohan [mailto:deepakwarrier@rediffmail.com]
> > Sent: Thursday, January 04, 2001 6:54 AM
> > To: sip@lists.bell-labs.com
> > Subject: [SIP] "method" parameter in "contact"
> >
> >
> > In which request/response will the "contact" header have the
> > "method" parameter, and what is the use?
>
> The primary use for the method parameter was when a URL was embedded in a
> web page. It indicates what method the UA should use. Very useful for things
> like:
>
> <html>
> You can send me an <a
> href="sip:jdrosen@dynamicsoft.com;method=message">Instant Message</a>.
> </html>
>
> I don't see much use in the method parameter within a SIP request itself.
>
> The SIP for presence documents talk about a "methods" parameter (NOTE the
> plural), but this is not a URL parameter, its a Contact header parameter,
> defined in the caller preferences specification.

Although I've noticed most of the examples in draft-rosenberg-impp-presence-00
are wrong and use "method", this lead to a number of the sip impp
implementations we saw at the bakeoff copying this.

James Undery



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 05:02:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08232
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 05:02:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 97E1344337; Tue,  9 Jan 2001 04:03:08 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60])
	by lists.bell-labs.com (Postfix) with ESMTP id DB66644336
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 04:02:24 -0500 (EST)
Received: from cvis01.gpt.co.uk (unverified) by cvis28.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc363f43c50ff6a103d@cvis28.marconicomms.com>;
 Tue, 9 Jan 2001 10:02:04 +0000
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-30) id KAA24340; Tue, 9 Jan 2001 10:01:59 GMT
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 802569CF.0037004C ; Tue, 9 Jan 2001 10:00:45 +0000
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Keith Robinson" <Keith.Robinson@marconi.com>
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
Cc: sip@lists.bell-labs.com, Steve Levy <stlevy@cisco.com>
Message-ID: <802569CF.0036FFC7.00@marconicomms.com>
Subject: Overlap sending with Record-Route is broken ( was [SIP] Overlap
	 Sending)
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=fCI4O7lcd6mxE0pCR9txqEdC5yYeIaLKoFxUBJ2I51EB32X3ZOvJjTRt"
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 10:00:54 +0000

--0__=fCI4O7lcd6mxE0pCR9txqEdC5yYeIaLKoFxUBJ2I51EB32X3ZOvJjTRt
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Hi,

I  take your point about requiring a proxy to route 6543231@sipgw.com the same
way as 65432@sipgw.com but I believe this to be entirely within the routing data
set up
by the administration. Allowing clients to choose there own path through the
network
to get to their desired destination using various digit sequences seems like the
classic way of
exposing networks to fraudulent use (billing avoidance, bypassing security,
etc). However,
I think this is a seperate issue.

I am still concerned about the Route header overwriting the R-URI and therefore
destroying the subsequent
digits when subsequent messages are routed using the Route header mechanism. I
am not sure that
putting the subsequent digits in the TO header helps because I believe the TO
URL is supposed to
be invariant during the lifetime of the call leg. Modifying the TO URL after the
initial INVITE I think will cause
problems for proxies  that are using the TO URL to match subsequent requests to
call legs in progress.

Without introducing a new header to carry the digit string, then I think the
only other way to make
overlap sending work is for the 484 to clear down the call leg as other 4XX
responses do and subsequent
INVITES with the original digits + additional digits to be a new INVITE (with a
new Call-Id). The initial INVITE
will not be routed using Route headers, so the digit string in the R-URI will
not be lost.  There still could be
a problem if the client has built a Route header (learnt out-of-band) and puts
this in the initial INVITE; the
same problem may occur.

Without clarification of this matter in the bis draft then I don't think overlap
sending is going to
be interoperable.

Regards,

K. Robinson.














Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 09/01/2001 07:36:51
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:      sip@lists.bell-labs.com                             
                                                              
 cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy          
          <stlevy@cisco.com>                                  
                                                              
                                                              
                                                              
 Subject: Re: [SIP] Overlap Sending                           
                                                              








Hi,

>>"I don't know. I haven't seen a proxy that would route depending on the
>>user, but it COULD happend. Let's assume , for example, that you do a
>>SRV DNS lookup, and get a list of servers. Then you MAY choose a
>>different server, for load balance purpose e.g., depending on the user
>>name. Just an example..."
>
>One way of ensuring that subsequent requests always traverse a given SIP
>node is for that node to Record-Route or supply a Contact ; it is likely
>that proxies and UAS at PSTN interworking points will require to stay in
>the signalling path during call setup so will do so.  Now, suppose one
>such node receives an initial INVITE with a R-URI of sip:654@sipgw.com
>and creates a Contact header thus:
>
> Contact: sip:654@sipgw.com;maddr=sipgw.com

Let's assume that the first proxy (P1) receives the R-URI
sip:654@sipgw.com and forwards it
to P2, which insert itself in the route and returns 484. The client then
sends 654123@sipgw.com, which goes via P1 to P2. P2 then forwards it
somewhere else etc., until it reaches the final UAS.

However, if the client would have sent 65412@sip.gw in the initial
INVITE, P1 would maybe have forwarded it to P3 instead of P2, which
means that the subsequent 654123@sipgw.com will take another route. This
may not be a problem, but again - you MAY want to send a specific number
via a specific proxy (for load balance/billing/monitoring/whatever
reason) - no matter if how the number is divided between INVITE
messages.

Again, this could be solved if you are able to configure the proxies.
And, if you don't own the proxies you could send some kind of digit map
header, telling the proxy to forward any matching number to the same
place (e.g. P2).

Then:

INVITE 654@sipgw.com
Forward-digit-map: 65xxxx

...would be treated, and forwarded by proxies, exactly like...

INVITE 654123@sipgw.com
Forward-digit-map: 65xxxx


A possible problem with this approach, though, is that the UAC would
tell the proxy what to do, but that is possible using the SIP Caller
Prefs anyway, so...

Just an idea...

>This is then returned in the 484 response so that the sending UA may
>build a Route header from it. Here is my first concern; will the sending
>UA treat the subsequent INVITE as a subsequent INVITE or as a new INVITE
>on a new Call-Id ? I ask because the 484 response is non-200 final
>response which implies that that call attempt has failed; obviously in
>this case it hasn't failed (not yet, anyway) its just been partially set
>up. Does this lead to special case handling for a particular 4XX response
>? In fact, the 484 is almost like an informational response.
>Would it be better to send an informational response (say 183) and the
>spec updated to allow subsequent INVITEs to be sent before the final ACK
>(a point raised by J. Rosenberg earlier on the list, but in a different
>context - to convey updated SDP information).

Allowing subsequent INVITEs before a final answer would also solve some
ISUP transparency issues. However, allowing it would probably - again -
produce lots of problematic cases (again, especially in a SIP/PSTN GW
scenario) and what-ifs, so IF it is to be allowed it should be very
cleary defined HOW and in WHAT FOR.

>Assuming the above is resolved one way or another, then a SIP node
>preceding sipgw.com is going to receive a subsequent INVITE for this call
>(containing additional digits 321)  that will look something like:
>
>INVITE sip:321@preceding.sipgw.com
>Route: sip:654@sipgw.com;maddr=sipgw.com
>
>As a Route header is present, this will be used to route the INVITE so
>therefore sipgw.com will receive an INVITE with the following Request
>Line:
>
>INVITE sip:654@sipgw.com;maddr=sipgw.com
>
>And here is a more worrying problem, the subsequent digits have been lost.
>The situation would be no better if the subsequent INVITE contained original
>digits plus subsequent digits; they would still be lost.
>
>The problem stems from the fact that the R-URI is supposed to be invariant at
>each node during the lifetime of the call leg, yet to do overlap sending it is
being
>used to convey new information so therefore does not remain invariant and other
parts of
>the protocol which assume it is invariant e.g., routing using the Route header
>break.
>Using a TEL URL does not help either; the digits would still be lost >after the
popping of the Route entry >into the R-URI.

Personally I don't see ANY case where TEL URL would help with ANYTHING
in a SIP network... :) It will just produce extra DNS lookup traffic.

>It would be easier to implement overlap sending if a seperate header
>could be used to convey the dialled digits, so an original INVITE may >look
something like:
>
>INVITE sip:digitdecode@sipgw.com
>Current-Dial-String: 01623
>
>The subsequent INVITES would then look something like:
>
>INVITE sip:digitdecode@sipgw.com;maddr=sipgw.com
>Current-Dial-String: 01623654398

Won't the To header show the current dial string, because it will not be
changed by proxies?

i.e.

INVITE sip:digitdecode@sipgw.com;maddr=sipgw.com
To: 01623@uas.com

...and the subsequent request...

INVITE sip:digitdecode@sipgw.com;maddr=sipgw.com
To: 01623654398@uas.com

>This ties in with your point of implementing a digit map header.
>
>Regards,
>
>K. Robinson.


Regards,

Christer Holmberg
Ericsson Finland



> Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 3:40:47
>
>
>
>
>
>
>
>  To:      sip@lists.bell-labs.com
>
>  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
>           <stlevy@cisco.com>
>
>
>
>  Subject: Re: [SIP] Overlap Sending
>
>
> Hi,
>
> >If a proxy, not serving uas.com, receives an INVITE with a R-URI of
4@uas.com,
> >why would it route it differently (Route headers not withstanding) from an
> INVITE
> >with a R-URI of 441@uas.com ?
>
> I don't know. I haven't seen a proxy that would route depending on the
> user, but it COULD happend. Let's assume , for example, that you do a
> SRV DNS lookup, and get a list of servers. Then you MAY choose a
> different server, for load balance purpose e.g., depending on the user
> name. Just an example...
>
> And, what happen if you use a TEL-URL, where you have to route depending
> on the user name (=telephone number). I guess using a ENUM DNS lookup
> COULD route it to the same host, but then I guess you would have to
> configure your DNS to for all the possible combinations (4.e164.arpa,
> 44.e164.arpa and 441.e164.arpa)...
>
> >Surely, if the proxy does not serve the domain identified in the R-URI it
> cannot
> >make any routing decisions based on the user part of the R-URI.
> >If, on the other hand, the proxy does serve uas.com, then it will be involved
> in
> >routing the call using the dialled digit string and I would expect it to know
> such things as minimum digits to
> >translation and perhaps even maximum number of digits to follow. Also,
because
> the proxy is doing digit based
> >routing it must be subject to the requirements of overlap sending so I would
> expect it to be stateful, at >least until call setup is complete, in which
case
> remembering previous call information would be reasonable. >In fact, such a
> proxy appears much like the interworking UAs I referred to previously and to
> which my question >applies.
>
> That was my point - that you also have to have support for this in your
> proxies, and not only in your client.
>
> I think the issue is that there are lots of what-ifs involved in this,
> and it should be specified how the specific cases are handled -
> especially by proxies and redirect servers.
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
> > Regards,
> >
> > K. Robinson
> >
> > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
> >
> >
> >
> >
> >
> >
> >
>
> Keith Robinson wrote:
> >
> > If a proxy, not serving uas.com, receives an INVITE with a R-URI of
4@uas.com,
> > why
> > would it route it differently (Route headers not withstanding) from an
INVITE
> > with a R-URI of 441@uas.com ?
> > Surely, if the proxy does not serve the domain identified in the R-URI it
> cannot
> > make any
> > routing decisions based on the user part of the R-URI.
> >
> > If, on the other hand, the proxy does serve uas.com, then it will be
involved
> in
> > routing the call using the dialled
> > digit string and I would expect it to know such things as minimum digits to
> > translation and perhaps even
> > maximum number of digits to follow. Also, because the proxy is doing digit
> based
> > routing it must be subject to the
> > requirements of overlap sending so I would expect it to be stateful, at
least
> > until call setup is complete, in which
> > case remembering previous call information would be reasonable. In fact,
such
> a
> > proxy appears much like the
> > interworking UAs I referred to previously and to which my question applies.
> >
> > Regards,
> >
> > K. Robinson
> >
> > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
> >
> >
> >
> >
> >
> >
> >
> >  To:      sip@lists.bell-labs.com
> >
> >  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
> >           <stlevy@cisco.com>
> >
> >
> >
> >  Subject: Re: [SIP] Overlap Sending
> >
> >
> > Hi,
> >
> > I think sending re-INVITES containing only subsequent digits will create
> > some problems. It's not enough that the UAS remembers the previous
> > INVITEs for the specific Call-ID, you may also have intermediate
> > redirect- and/or proxy servers that make their redirect/forwarding
> > decissions based on the destination number, and then they would also
> > have to remember the previous INVITEs, and they would possible also have
> > to be able to know if, and in some cases, how many digits will follow
> > (e.g. 4@uas.com may be routed to a complete destination than
> > 441@uas.com, etc.) Maybe we should implement some kind of digit-map
> > header, or something... :)
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> > Keith Robinson wrote:
> > >
> > > Yes, this is the type of case I have in mind. The question I have is what
> are
> > > the subsequent INVITES; are they
> > >
> > > a) New INVITES, on a new Call-Id containing the original digits (from
> original
> > > INVITE) + subsequent digits ?
> > >
> > > or
> > >
> > > b) re-INVITES containing only subsequent digits ?
> > >
> > > or
> > >
> > > c) re-INVITES containing original digits + subsequent digits ?
> > >
> > > The sending UAs I referred to in my previous note are those that sit in
> > PSTN/SIP
> > > gateways,
> > > not necessarily an originating UA sitting on someones desktop.
> > >
> > > So, the question applies as much to these interworking UAs for
constructing
> > > the subsequent INVITEs as well as to receiving UAs for interpreting them.
> > >
> > > Regards,
> > >
> > > K. Robinson.
> > >
> > > Steve Levy <stlevy@cisco.com> on 05/01/2001 22:32:00
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  To:      Keith Robinson/MAIN/MC1@MCMAIN,
> > >           sip@lists.bell-labs.com
> > >
> > >  cc:
> > >
> > >
> > >
> > >  Subject: Re: [SIP] Overlap Sending
> > >
> > >
> > > Hi Keith,
> > >
> > > I was wondering if in considering overlap sending issues and SIP if you
were
> > > considering the case of overlap sending across multiple networks with
> variable
> > > length digits.
> > >
> > > In this case, in order to avoid post dial delay, the digits need to be
> passed
> > > through the networks to the final destiantion network prior to end of dial
> > > (since the destination network is the only network that knows how many
> digits
> > > are required). So in effect there may be additional digits sent after an
> > INVITE
> > > has been received and sent downstream to the callee.
> > >
> > > Thanks,
> > > Steve
> > >
> > > At 03:50 PM 1/5/01 +0000, Keith Robinson wrote:
> > > >
> > > >
> > > >I have the following query regarding overlap sending as defined in
> > > >rfc2543bis-02:
> > > >
> > > >Section 4.2.1 states the following:
> > > >
> > > >"...the UAS compares the Request-URI with Request-URI of the previous
> INVITE
> > > >request
> > > >for the same Call-Id. If the Request-URI  contains additional digits in
the
> > > >'user' part, the UAS
> > > >treats the INVITE as adding additional digits to the original dialed
> string."
> > > >
> > > >This appears to imply that the subsequent INVITE contains the original
> > dialled
> > > >string plus the
> > > >additional digits; if this is the case, then there is no need for the UAS
> to
> > > >remember the
> > > >previous string, and therefore no need to keep any state regarding the
> > previous
> > > >attempt.
> > > >The subsequent INVITE can really be a new INVITE., i.e. a new Call-Id.
> > > >
> > > >If, on the other hand, the sending UA only sends additional digits, then
> the
> > > >original digits
> > > >will have to be remembered by the UAS, and the INVITE matched up with
this
> > > >state
> > > >so
> > > >this INVITE must be on the same Call-Id.
> > > >
> > > >This latter case is similar to the way existing telephony protocols
> transmit
> > > >addtional digits
> > > >when doing overlap sending.
> > > >
> > > >So, upon receiving a response of 484 Address Incomplete, does the sending
> UA
> > > >send
> > > >original digits plus aditional digits on a new Call-Id or additional
digits
> > > >only
> > > >on the same
> > > >Call-Id with an incremented Cseq.
> > > >
> > > >Regards,
> > > >
> > > >K. Robinson.
> > > >
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >SIP mailing list
> > > >SIP@lists.bell-labs.com
> > > >http://lists.bell-labs.com/mailman/listinfo/sip
> > >
> > > _______________________________________________
> > > SIP mailing list
> > > SIP@lists.bell-labs.com
> > > http://lists.bell-labs.com/mailman/listinfo/sip
> > >
> > > _______________________________________________
> > > SIP mailing list
> > > SIP@lists.bell-labs.com
> > > http://lists.bell-labs.com/mailman/listinfo/sip

--0__=fCI4O7lcd6mxE0pCR9txqEdC5yYeIaLKoFxUBJ2I51EB32X3ZOvJjTRt
Content-type: application/octet-stream; 
	name="christer.holmberg.vcf"
Content-Disposition: attachment; filename="christer.holmberg.vcf"
Content-Transfer-Encoding: base64

YmVnaW46dmNhcmQgDQpuOkhvbG1iZXJnO0NocmlzdGVyDQp0ZWw7Y2VsbDorMzU4LTQwLTU2MDQ0
MTINCnRlbDt3b3JrOiszNTgtOS0yOTkyOTQzDQp4LW1vemlsbGEtaHRtbDpGQUxTRQ0Kb3JnOkVy
aWNzc29uO0lQIE11bHRpbWVkaWEgLyBBZHZhbmNlZCBTaWduYWxsaW5nIFJlc2VhcmNoIExhYm9y
YXRvcnkNCmFkcjo7Ozs7OzsNCnZlcnNpb246Mi4xDQplbWFpbDtpbnRlcm5ldDpjaHJpc3Rlci5o
b2xtYmVyZ0BsbWYuZXJpY3Nzb24uc2UNCnRpdGxlOlN5c3RlbSBEZXNpZ25lcg0KZm46Q2hyaXN0
ZXIgSG9sbWJlcmcNCmVuZDp2Y2FyZA0KDQo=

--0__=fCI4O7lcd6mxE0pCR9txqEdC5yYeIaLKoFxUBJ2I51EB32X3ZOvJjTRt--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 05:21:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08319
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 05:21:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C03B044371; Tue,  9 Jan 2001 04:22:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from nwcst285.netaddress.usa.net (nwcst285.netaddress.usa.net [204.68.23.30])
	by lists.bell-labs.com (Postfix) with SMTP id 337104436B
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 04:21:17 -0500 (EST)
Received: (qmail 13183 invoked by uid 60001); 9 Jan 2001 10:21:05 -0000
Message-ID: <20010109102105.13182.qmail@nwcst285.netaddress.usa.net>
Received: from 204.68.23.30 by nwcst285 for [203.197.178.200] via web-mailer(34FM.0700.15.02) on Tue Jan  9 10:21:04 GMT 2001
From: Nishith Chudasama <nishith76@usa.net>
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
        Nishith Chudasama <nishith76@usa.net>
Subject: Re: [Re: [SIP] DNS Lookup]
Cc: sip@lists.bell-labs.com, vijethd@rediffmail.com
X-Mailer: USANET web-mailer (34FM.0700.15.02)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 9 Jan 2001 03:21:04 MST
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA08319

Thanks for the info. I downloaded the utility. One more help that I need is
for using it in a LAN.
I am not able to resolve any host names since the machine on which I am
running it is on LAN and is not directly connected to the internet. Proxy
setting is available for browser application. But I need to set a proxy for
testres application. How can I do it?

Nishith.

"Henning G. Schulzrinne" <hgs@cs.columbia.edu> wrote:
Nishith Chudasama wrote:
> 
> Hi all,
> 
> Can anybody let me know if there is some readymade piece of code available
on
> the net for DNS queries for SIP clients/Servers.
> 
> If not, can anybody point to the document specifying the procedure for
doing
> this?

http://www.cs.columbia.edu/sip/implementations.html has a link to an
SRV-enhanced resparse implementation.


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs


____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 05:50:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08537
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 05:50:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5091C44369; Tue,  9 Jan 2001 04:51:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lists.bell-labs.com (Postfix) with ESMTP id 7F2E844337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 04:50:31 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f09AoEC21187;
	Tue, 9 Jan 2001 11:50:14 +0100 (MET)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.40])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA11965;
	Tue, 9 Jan 2001 12:50:12 +0200 (EET)
Message-ID: <3A5AECDE.B394D16F@lmf.ericsson.se>
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Cc: Keith Robinson <Keith.Robinson@marconi.com>, Steve Levy <stlevy@cisco.com>
Subject: Re: [SIP] Overlap Sending
References: <802569CE.005CD879.00@marconicomms.com>
Content-Type: multipart/mixed;
 boundary="------------A27D7A6737313BE5A73AF9CB"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 12:50:06 +0200

This is a multi-part message in MIME format.
--------------A27D7A6737313BE5A73AF9CB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

>I take your point about requiring a proxy to route 6543231@sipgw.com the same
>way as 65432@sipgw.com but I believe this to be entirely within the routing data
>set up by the administration. Allowing clients to choose there own path through the
>network to get to their desired destination using various digit sequences seems like the
>classic way of exposing networks to fraudulent use (billing avoidance, bypassing security,
>etc). However, I think this is a seperate issue.

Well, it's related :)

>I am still concerned about the Route header overwriting the R-URI and therefore
>destroying the subsequent digits when subsequent messages are routed using the Route header mechanism. I
>am not sure that putting the subsequent digits in the TO header helps because I believe the TO
>URL is supposed to be invariant during the lifetime of the call leg. 

Well, this depends a little on how you define a call leg, I guess...
Since you got a 4xx response to your first INVITE, you didn't manage to
set up a call leg, so then you try to set up a "new" call leg - with a
new R-URI and To header...

INVITE 123@sipgw.com
To: 123@sipgw.com

<---- 484 -----

INVITE 123456@sipgw.com
To: 123456@sipgw.com

>Modifying the TO URL after the initial INVITE I think will cause problems for proxies  that are using the TO >URL to match subsequent requests to call legs in progress.

Since the proxy sent back 484, I wouldn't consider the call leg to be in
progress anymore (after the proxy receive the ACK, that is). 

And, the proxy will probably have to do the routing based on the To
header, since the R-URI will probably (unless we use an outbound proxy)
be the address of the proxy itself, so if the To header isn't changed
the proxy will try to route 123@sipgw.com every time, even if more
digits have provided by the client. And, if the proxy is supposed to
"combine" the Current-Dial-String header value with the To header, to be
able to route, I think that the client could put the new value in the To
header from the beginning. Because, if the proxy doesn't support the
Current-Dial-String it wouldn't be able to do anything, since both the
R-URI and To header could be the same in the subsequent INVITEs. If you
have a updated To header, and the proxy doesn't support the digitmap, it
would at least be able to route the new To header - even if the message
may take a "wrong" route.
 
>Without introducing a new header to carry the digit string, then I think the
>only other way to make overlap sending work is for the 484 to clear down the call leg as other 4XX
>responses do and subsequent INVITES with the original digits + additional digits to be a new INVITE (with a
>new Call-Id).

I agree, but I don't think it requires a new Call-Id. Then we could
still define a digitmap header to make sure  (if it is supported by the
proxy) that the proxy will always route the message correctly, no matter
how many INVITEs you need to provide all digits.

>The initial INVITE will not be routed using Route headers, so the digit string in the R-URI will
>not be lost.

Proxies may change the R-URI...

>There still could be a problem if the client has built a Route header (learnt out-of-band) and puts
>this in the initial INVITE; the same problem may occur.

This will not be a problem if all servers in the path support the
digitmap... :)
 
>Without clarification of this matter in the bis draft then I don't think overlap
>sending is going to be interoperable.

I agree. 

Personally I think (no, this is NOT a proposal to re-write SIP :) the
best way would be to have some kind of "multi-message" setup, and that
would also solve a number of other issues (i.e. ISUP transparency).

Regards,

Christer Holmberg
Ericsson Finland






Keith Robinson wrote:
> 
> Let's consider the following point:
> 
> "I don't know. I haven't seen a proxy that would route depending on the
> user, but it COULD happend. Let's assume , for example, that you do a
> SRV DNS lookup, and get a list of servers. Then you MAY choose a
> different server, for load balance purpose e.g., depending on the user
> name. Just an example..."
> 
> One way of ensuring that subsequent requests always traverse a given SIP
> node is for that node to Record-Route or supply a Contact ; it is likely that
> proxies and
> UAS at PSTN interworking points will require to stay in the signalling path
> during
> call setup so will do so.  Now, suppose one such node receives an initial INVITE
> with
> a R-URI of sip:654@sipgw.com and creates a Contact header thus:
> 
> Contact: sip:654@sipgw.com;maddr=sipgw.com
> 
> This is then returned in the 484 response so that the sending UA may build a
> Route header from it. Here is my first concern; will the sending UA treat the
> subsequent INVITE as a subsequent INVITE or as a new INVITE on a new
> Call-Id ? I ask because the 484 response is non-200 final response which
> implies that that call attempt has failed; obviously in this case it hasn't
> failed
> (not yet, anyway) its just been partially set up.  Does this lead to special
> case handling
> for a particular 4XX response ? In fact, the 484 is almost like an informational
> response.
> Would it be better to send an informational response (say 183) and the spec
> updated to
> allow subsequent INVITEs to be sent before the final ACK (a point raised by J.
> Rosenberg
> earlier on the list, but in a different context - to convey updated SDP
> information).
> 
> Assuming the above is resolved one way or another, then a SIP node preceding
> sipgw.com is going to receive a subsequent INVITE for this call (containing
> additional
> digits 321)  that will look something like:
> 
> INVITE sip:321@preceding.sipgw.com
> Route: sip:654@sipgw.com;maddr=sipgw.com
> 
> As a Route header is present, this will be used to route the INVITE so
> therefore sipgw.com will receive an INVITE with the following Request
> Line:
> 
> INVITE sip:654@sipgw.com;maddr=sipgw.com
> 
> And here is a more worrying problem, the subsequent digits have been lost.
> The situation would be no better if the subsequent INVITE contained original
> digits
> plus subsequent digits; they would still be lost.
> 
> The problem stems from the fact that the R-URI is supposed to be invariant at
> each
> node during the lifetime of the call leg, yet to do overlap sending it is being
> used to
> convey new information so therefore does not remain invariant and other parts of
> the
> protocol which assume it is invariant e.g., routing using the Route header
> break.
> 
> Using a TEL URL does not help either; the digits would still be lost after the
> popping of
> the Route entry into the R-URI.
> 
> It would be easier to implement overlap sending if a seperate header could be
> used to
> convey the dialled digits, so an original INVITE may look something like:
> 
> INVITE sip:digitdecode@sipgw.com
> Current-Dial-String: 01623
> 
> The subsequent INVITES would then look something like:
> 
> INVITE sip:digitdecode@sipgw.com;maddr=sipgw.com
> Current-Dial-String: 01623654398
> 
> This ties in with your point of implementing a digit map header.
> 
> Regards,
> 
> K. Robinson.
> 
> Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 13:40:47
> 
> 
> 
> 
> 
> 
> 
>  To:      sip@lists.bell-labs.com
> 
>  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
>           <stlevy@cisco.com>
> 
> 
> 
>  Subject: Re: [SIP] Overlap Sending
> 
> 
> Hi,
> 
> >If a proxy, not serving uas.com, receives an INVITE with a R-URI of 4@uas.com,
> >why would it route it differently (Route headers not withstanding) from an
> INVITE
> >with a R-URI of 441@uas.com ?
> 
> I don't know. I haven't seen a proxy that would route depending on the
> user, but it COULD happend. Let's assume , for example, that you do a
> SRV DNS lookup, and get a list of servers. Then you MAY choose a
> different server, for load balance purpose e.g., depending on the user
> name. Just an example...
> 
> And, what happen if you use a TEL-URL, where you have to route depending
> on the user name (=telephone number). I guess using a ENUM DNS lookup
> COULD route it to the same host, but then I guess you would have to
> configure your DNS to for all the possible combinations (4.e164.arpa,
> 44.e164.arpa and 441.e164.arpa)...
> 
> >Surely, if the proxy does not serve the domain identified in the R-URI it
> cannot
> >make any routing decisions based on the user part of the R-URI.
> >If, on the other hand, the proxy does serve uas.com, then it will be involved
> in
> >routing the call using the dialled digit string and I would expect it to know
> such things as minimum digits to
> >translation and perhaps even maximum number of digits to follow. Also, because
> the proxy is doing digit based
> >routing it must be subject to the requirements of overlap sending so I would
> expect it to be stateful, at >least until call setup is complete, in which case
> remembering previous call information would be reasonable. >In fact, such a
> proxy appears much like the interworking UAs I referred to previously and to
> which my question >applies.
> 
> That was my point - that you also have to have support for this in your
> proxies, and not only in your client.
> 
> I think the issue is that there are lots of what-ifs involved in this,
> and it should be specified how the specific cases are handled -
> especially by proxies and redirect servers.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> > Regards,
> >
> > K. Robinson
> >
> > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
> >
> >
> >
> >
> >
> >
> >
> 
> Keith Robinson wrote:
> >
> > If a proxy, not serving uas.com, receives an INVITE with a R-URI of 4@uas.com,
> > why
> > would it route it differently (Route headers not withstanding) from an INVITE
> > with a R-URI of 441@uas.com ?
> > Surely, if the proxy does not serve the domain identified in the R-URI it
> cannot
> > make any
> > routing decisions based on the user part of the R-URI.
> >
> > If, on the other hand, the proxy does serve uas.com, then it will be involved
> in
> > routing the call using the dialled
> > digit string and I would expect it to know such things as minimum digits to
> > translation and perhaps even
> > maximum number of digits to follow. Also, because the proxy is doing digit
> based
> > routing it must be subject to the
> > requirements of overlap sending so I would expect it to be stateful, at least
> > until call setup is complete, in which
> > case remembering previous call information would be reasonable. In fact, such
> a
> > proxy appears much like the
> > interworking UAs I referred to previously and to which my question applies.
> >
> > Regards,
> >
> > K. Robinson
> >
> > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
> >
> >
> >
> >
> >
> >
> >
> >  To:      sip@lists.bell-labs.com
> >
> >  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
> >           <stlevy@cisco.com>
> >
> >
> >
> >  Subject: Re: [SIP] Overlap Sending
> >
> >
> > Hi,
> >
> > I think sending re-INVITES containing only subsequent digits will create
> > some problems. It's not enough that the UAS remembers the previous
> > INVITEs for the specific Call-ID, you may also have intermediate
> > redirect- and/or proxy servers that make their redirect/forwarding
> > decissions based on the destination number, and then they would also
> > have to remember the previous INVITEs, and they would possible also have
> > to be able to know if, and in some cases, how many digits will follow
> > (e.g. 4@uas.com may be routed to a complete destination than
> > 441@uas.com, etc.) Maybe we should implement some kind of digit-map
> > header, or something... :)
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> > Keith Robinson wrote:
> > >
> > > Yes, this is the type of case I have in mind. The question I have is what
> are
> > > the subsequent INVITES; are they
> > >
> > > a) New INVITES, on a new Call-Id containing the original digits (from
> original
> > > INVITE) + subsequent digits ?
> > >
> > > or
> > >
> > > b) re-INVITES containing only subsequent digits ?
> > >
> > > or
> > >
> > > c) re-INVITES containing original digits + subsequent digits ?
> > >
> > > The sending UAs I referred to in my previous note are those that sit in
> > PSTN/SIP
> > > gateways,
> > > not necessarily an originating UA sitting on someones desktop.
> > >
> > > So, the question applies as much to these interworking UAs for constructing
> > > the subsequent INVITEs as well as to receiving UAs for interpreting them.
> > >
> > > Regards,
> > >
> > > K. Robinson.
> > >
> > > Steve Levy <stlevy@cisco.com> on 05/01/2001 22:32:00
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  To:      Keith Robinson/MAIN/MC1@MCMAIN,
> > >           sip@lists.bell-labs.com
> > >
> > >  cc:
> > >
> > >
> > >
> > >  Subject: Re: [SIP] Overlap Sending
> > >
> > >
> > > Hi Keith,
> > >
> > > I was wondering if in considering overlap sending issues and SIP if you were
> > > considering the case of overlap sending across multiple networks with
> variable
> > > length digits.
> > >
> > > In this case, in order to avoid post dial delay, the digits need to be
> passed
> > > through the networks to the final destiantion network prior to end of dial
> > > (since the destination network is the only network that knows how many
> digits
> > > are required). So in effect there may be additional digits sent after an
> > INVITE
> > > has been received and sent downstream to the callee.
> > >
> > > Thanks,
> > > Steve
> > >
> > > At 03:50 PM 1/5/01 +0000, Keith Robinson wrote:
> > > >
> > > >
> > > >I have the following query regarding overlap sending as defined in
> > > >rfc2543bis-02:
> > > >
> > > >Section 4.2.1 states the following:
> > > >
> > > >"...the UAS compares the Request-URI with Request-URI of the previous
> INVITE
> > > >request
> > > >for the same Call-Id. If the Request-URI  contains additional digits in the
> > > >'user' part, the UAS
> > > >treats the INVITE as adding additional digits to the original dialed
> string."
> > > >
> > > >This appears to imply that the subsequent INVITE contains the original
> > dialled
> > > >string plus the
> > > >additional digits; if this is the case, then there is no need for the UAS
> to
> > > >remember the
> > > >previous string, and therefore no need to keep any state regarding the
> > previous
> > > >attempt.
> > > >The subsequent INVITE can really be a new INVITE., i.e. a new Call-Id.
> > > >
> > > >If, on the other hand, the sending UA only sends additional digits, then
> the
> > > >original digits
> > > >will have to be remembered by the UAS, and the INVITE matched up with this
> > > >state
> > > >so
> > > >this INVITE must be on the same Call-Id.
> > > >
> > > >This latter case is similar to the way existing telephony protocols
> transmit
> > > >addtional digits
> > > >when doing overlap sending.
> > > >
> > > >So, upon receiving a response of 484 Address Incomplete, does the sending
> UA
> > > >send
> > > >original digits plus aditional digits on a new Call-Id or additional digits
> > > >only
> > > >on the same
> > > >Call-Id with an incremented Cseq.
> > > >
> > > >Regards,
> > > >
> > > >K. Robinson.
> > > >
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >SIP mailing list
> > > >SIP@lists.bell-labs.com
> > > >http://lists.bell-labs.com/mailman/listinfo/sip
> > >
> > > _______________________________________________
> > > SIP mailing list
> > > SIP@lists.bell-labs.com
> > > http://lists.bell-labs.com/mailman/listinfo/sip
> > >
> > > _______________________________________________
> > > SIP mailing list
> > > SIP@lists.bell-labs.com
> > > http://lists.bell-labs.com/mailman/listinfo/sip
--------------A27D7A6737313BE5A73AF9CB
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------A27D7A6737313BE5A73AF9CB--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 06:34:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08693
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 06:34:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B511F4434B; Tue,  9 Jan 2001 05:35:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb12.rediffmail.com (unknown [203.199.83.28])
	by lists.bell-labs.com (Postfix) with SMTP id 0098044337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 05:34:20 -0500 (EST)
Received: (qmail 20707 invoked by uid 510); 9 Jan 2001 11:25:39 -0000
Message-ID: <20010109112538.20705.qmail@mailweb12.rediffmail.com>
Received: from unknown (203.195.147.10) by rediffmail.com via HTTP; 09 Jan 2001 11:25:38 -0000
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
From: "Deepak  Mohan" <deepakwarrier@rediffmail.com>
Content-ID: <Tue_Jan__9_16_55_38_IST_2001_0@mailweb12.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Subject: [SIP] OPTIONS method, bug in draft-ietf-sip-rfc2543bis-02
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 9 Jan 2001 11:25:38 -0000
Content-Transfer-Encoding: 7bit

In table 4 and 5 of draft-ietf-sip-rfc2543bis-02, the OPTIONS message cannot have the "Expires" or the "Priority" headers.

Couldn't the "Expires" header be used to *check* if a call can be established using OPTIONS, within the specified time?

Similarly, couldn't "Priority" be used to *check* if a call will succeed through a heavily-laden proxy that uses "Priority" to filter out calls (to reduce the load)? It is true that even sending an OPTIONS will un-necessarily increase the load on the proxy.

Regarding the bug in draft-ietf-sip-rfc2543bis-02, I think "6.46 User-Agent" is supposed to refer to H14.43 and not "H14.42" as mentioned.

Thanks,
Deepak



_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 07:24:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09491
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 07:24:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 305BC4434B; Tue,  9 Jan 2001 06:25:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb11.rediffmail.com (unknown [203.199.83.27])
	by lists.bell-labs.com (Postfix) with SMTP id 398E344337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 06:24:22 -0500 (EST)
Received: (qmail 22916 invoked by uid 510); 9 Jan 2001 12:21:18 -0000
Message-ID: <20010109122118.22915.qmail@mailweb11.rediffmail.com>
Received: from unknown (203.197.231.11) by rediffmail.com via HTTP; 09 Jan 2001 12:21:18 -0000
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
Subject:  [SIP] Proxy and Redirect Servers
From: "Divya  Nath" <divyanath@rediffmail.com>
Content-ID: <Tue_Jan__9_17_51_13_IST_2001_0@mailweb11.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 9 Jan 2001 12:21:18 -0000
Content-Transfer-Encoding: 7bit

Hi ,
     In section 4.2 of the internet draft 
ietf-sip-rfc2543-bis-0.2ps the following is written 

"Proxy and redirect servers treat all methods other than 
INVITE and CANCEL in the same way, by forwarding them accordingly"

Can anybody clearify how proxy and redirect servers treat all other methods in the same way?

Thanx and regards
Divya

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 07:31:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09674
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 07:31:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1F5AD44363; Tue,  9 Jan 2001 06:32:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id 660D244363
	for <SIP@lists.bell-labs.com>; Tue,  9 Jan 2001 06:31:22 -0500 (EST)
Received: from ms.uab.ericsson.se (ms-blue.uab.ericsson.se [134.138.224.109])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f09CVAd18848
	for <SIP@lists.bell-labs.com>; Tue, 9 Jan 2001 13:31:10 +0100 (MET)
Received: from uabx04c384.uab.ericsson.se..uab.ericsson.se (uabx04c384 [134.138.229.144])
	by ms.uab.ericsson.se (8.11.1/8.11.1/uab-3.3) with ESMTP id f09CV9C06099
	for <SIP@lists.bell-labs.com>; Tue, 9 Jan 2001 13:31:09 +0100 (MET)
Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se..uab.ericsson.se (8.8.7/client-1.3uab1)
	id NAA08573; Tue, 9 Jan 2001 13:31:08 +0100 (MET)
Message-ID: <3A5B048B.FAC0AA76@uab.ericsson.se>
From: Bertil Engelholm <Bertil.Engelholm@uab.ericsson.se>
Organization: Ericsson Utvecklings AB
X-Mailer: Mozilla 4.76C-CCK-MCD  [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: sv,en-US
MIME-Version: 1.0
To: SIP@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] CANCEL problem ??
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 13:31:07 +0100
Content-Transfer-Encoding: 7bit

Hi,

I have tried to implement CANCEL handling in our proxy
and by doing so I have come up with a problem I don't
know how to handle.

The way I have understood CANCEL is that it's sent hop
to hop which means when a proxy receives a CANCEL for
an ongoing transaction the proxy will send a 487 response
to the original request and then send a 200 OK response
to the CANCEL. The proxy will also send a CANCEL to all
branches it has created due to the original transaction.

I also interpret the specification so that if I have
already sent a final response to the original request I
should not cancel the transaction but still send a 200
response to the CANCEL request ??

The problem I don't know how to handle is the following :

------   ------   ------   ------
| Ca |---| P1 |---| P2 |---| Cb |
------   ------   ------   ------

If Ca sends e.g. an INVITE to Cb which is proxied through
P1 and P2. Cb returns 180 RINGING back to Ca.
Ca now sends a CANCEL to cancel the INVITE. The CANCEL 
reaches P1 which sends a 487 to the INVITE and a 200 to
the CANCEL and then sends a CANCEL to P2. If Cb answers
the call during this time a 200 OK is on it's way from
P2 to P1. So what should P1 do when it receives a 200
OK on the original request instead of a 487 ?? 
Should P1 ACK the 200 OK to avoid retransmission ??
What if the 200 response was lost between P2 and P1 ??
In case of a INVITE it will be retransmitted but what
if it's another type of request that was cancelled ?

Since P2 thinks the transaction is completed it will 
not do anything on the CANCEL except sending a 200
response to the CANCEL. This means that Ca and P1 
thinks the transaction is cancelled but P2 and Cb
thinks it still is going on ?? This also means that 
they will retransmit the 200 OK for quite a while.

Another question related to this case is when the
user at Cb hangs up can Cb cancel the transaction ?
Or is it only the side that originated a transaction
that can cancel it ??

/Bertil
 
-- 
Bertil Engelholm
AXE Research and Development        voice : +46 8 727 3499
SIP Security                        Fax   : +46 8 647 8276
S-126 25 Stockholm Sweden           E-mail:
Bertil.Engelholm@uab.ericsson.se

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 07:49:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09989
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 07:49:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3A9F344382; Tue,  9 Jan 2001 06:50:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id 8080A44381
	for <SIP@lists.bell-labs.com>; Tue,  9 Jan 2001 06:49:46 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 9 Jan 2001 12:49:35 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id MAA17977; Tue, 9 Jan 2001 12:48:11 GMT
From: "Jo Hornsby" <jhornsby@ubiquity.net>
To: "Bertil Engelholm" <Bertil.Engelholm@uab.ericsson.se>,
        <SIP@lists.bell-labs.com>
Subject: RE: [SIP] CANCEL problem ??
Message-ID: <001201c07a3a$6be3ffd0$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <3A5B048B.FAC0AA76@uab.ericsson.se>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 12:48:10 -0000
Content-Transfer-Encoding: 7bit

Bertil wrote:
> I have tried to implement CANCEL handling in our proxy
> and by doing so I have come up with a problem I don't
> know how to handle.
> 
> The way I have understood CANCEL is that it's sent hop
> to hop which means when a proxy receives a CANCEL for
> an ongoing transaction the proxy will send a 487 response
> to the original request and then send a 200 OK response
> to the CANCEL. The proxy will also send a CANCEL to all
> branches it has created due to the original transaction.

Almost.  The proxy should do as you say; however, it should
not send the 487; rather, it should wait for responses on
all branches as it normally would do.

There is an issue here, however, if a proxy happens to have
an "older" (i.e., non-487 aware) server at the end of one of
its branches.  In this case, it will probably not get a final
response to the INVITE (or whatever).  A solution to this is
to start a timer when a CANCEL has been issued, and if this
timer expires, then "imagine" that you got a 487 along that
branch.

The difficulty is what value to use for the timer.  There
was some discussion about this a while back. Have a look at
the thread entitled:
"CANCEL - response sequence issue (again)"
(it was mid-late October).

> I also interpret the specification so that if I have
> already sent a final response to the original request I
> should not cancel the transaction but still send a 200
> response to the CANCEL request ??

Yup.

> The problem I don't know how to handle is the following :
> 
> ------   ------   ------   ------
> | Ca |---| P1 |---| P2 |---| Cb |
> ------   ------   ------   ------
> 
> If Ca sends e.g. an INVITE to Cb which is proxied through
> P1 and P2. Cb returns 180 RINGING back to Ca.
> Ca now sends a CANCEL to cancel the INVITE. The CANCEL 
> reaches P1 which sends a 487 to the INVITE and a 200 to
> the CANCEL and then sends a CANCEL to P2. If Cb answers
> the call during this time a 200 OK is on it's way from
> P2 to P1. So what should P1 do when it receives a 200
> OK on the original request instead of a 487 ?? 
> Should P1 ACK the 200 OK to avoid retransmission ??

Although what I said above already addresses this problem,
in any case, 200s (to INVITEs) should _always_ be forwarded,
and they certainly should not be ACK d by proxies.

> What if the 200 response was lost between P2 and P1 ??
> In case of a INVITE it will be retransmitted but what
> if it's another type of request that was cancelled ?
> 
> Since P2 thinks the transaction is completed it will 
> not do anything on the CANCEL except sending a 200
> response to the CANCEL. This means that Ca and P1 
> thinks the transaction is cancelled but P2 and Cb
> thinks it still is going on ?? This also means that 
> they will retransmit the 200 OK for quite a while.
> 
> Another question related to this case is when the
> user at Cb hangs up can Cb cancel the transaction ?
> Or is it only the side that originated a transaction
> that can cancel it ??

Only the originating client, and intermediate proxies
(in the downstream "direction") can CANCEL.

HTH,


 - Jo.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 07:54:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10152
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 07:54:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 963214437D; Tue,  9 Jan 2001 06:55:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by lists.bell-labs.com (Postfix) with ESMTP id 5A21644337
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 12:10:31 -0500 (EST)
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Mon, 8 Jan 2001 13:09:52 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBRB9Z>; Mon, 8 Jan 2001 13:09:54 -0500
Message-ID: <28560036253BD41191A10000F8BCBD1103474549@zcard00g.ca.nortel.com>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@americasm01.nt.com>
To: Rohan Mahy <rohan@cisco.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] REFER open issues
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0799E.3213B580"
X-Orig: <taylor@americasm01.nt.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 13:09:51 -0500

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_01C0799E.3213B580
Content-Type: text/plain;
	charset="iso-8859-1"

I think part of the problem is to agree on the requirements the method is to
satisfy.  On one side of the debate, we've had pressure to restrict REFER
functionality to call transfer.  On the other is Jonathan's vision of a set
of general primitives.  Thus to add to Rohan's valuable roundup of issues
below, I add a list of alternative functional requirements.  Just to make it
clear that I have my own views on the matter, I list my preferred
alternative first in each case.
 
1) Relation to existing session
(a) REFER can be sent independently of any existing session.
(b) REFER can only be sent on an already-existing call-leg.
(c) ...
 
2) Method invoked by REFER
(a) Any method can be invoked, including BYE.
(b) REFER always asks the receiving party to send an INVITE.
(c) REFER-eligibility varies and must be documented on a per-method basis.
 
3) Notification of results
(a) REFER implicitly subscribes to SIP events at the receiver 
(b) The referror must issue an explicit SUBS to get notification
 
4) Join vs. Replace vs. New
(a) Explicit indication of intent in a header
(b) ...
Note that this is an issue for any receiver of an INVITE, not necessarily
tied to REFER.  As such, it is a matter for another thread, which I will
initiate.

-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Monday, January 08, 2001 11:20 AM
To: sip@lists.bell-labs.com
Subject: Re: [SIP] REFER open issues


 [meeting proposal snipped]
 
 At 10:08 AM 12/15/00 , Rohan Mahy wrote:
>Hi,
>
>I'd like to summarize ALL the open issues that we have with REFER.  In the
>interest of coming to consensus, I'd like to invite interested implementers
>who have comments to meet in person before Minneapolis to close REFER open
>issues.  If folks think this is a good idea, we would certainly post the
>minutes and partial consensus back to the list for comments/changes.  As a
>strawman, I will suggest sometime in the last week of January.  A few
>plausible locations are: Dallas, New York, San Jose...  I volunteer to
>organize this if necessary.
>
>A short summary of the issues are below in no particular order:
>
>1) Retransmission problem:
>Robert Sparks already summarized this problem in his recent post.
>(a) REFER completes early, use explicit SUBSCRIBE for more info
>(b) REFER completes early and implicitly SUBSCRIBEs to more info
>(c) REFER completes after 16 secs and provides URL for SUBSCRIBE
>(d) send new REFER (new CSeq same call ID) after 32 seconds.
>
>2) Cancellation:
>If REFER returns a final response before a long INVITE transaction
>completes, how do you cancel that INVITE?  
>(a) send same REFER with ;method=CANCEL
>(b) send REFERCANCEL method
>
>3) Call-leg matching:
>Should you include call-id's in Refer-to URLs?  If not, what do you use for
>matching (Replaces or similar)?
>(a) match call-ids
>(b) use a Replaces header
>(c) use the mesh-id to setup mesh, then say BYE
>(d) use a new header
>
>4) If we choose Replaces or the like, how do we express that we want to
>*join* 2 legs via REFER?
>(a) Join header
>(b) Associate header
>(c) new method
>(d) something else
>
>5) If Refer-To contains parameters (method, transport), or potentially
>contradictory headers, what do we do with them?
>(a) allow all of them if authorized
>(b) allow a subset of methods/headers
>(c) send an error mesage
>(d) ignore the headers/parameters
>(e) ignore the whole message
>
>6) If we don't allow  ;method=BYE, how do we solve the problem described in
>the Music on 
>Hold flow?
>(a) method=BYE
>(b) ???
>
>7) How do we ask devices to do stuff for us?  [probably defer this issue]
>(a) REFER with parameters/headers
>(b) PHONECTL
>(c) some NEWMETHOD
>(d) Mbus
>(e) other
>
>Any other REFER open issues I missed?
>
>thanks,
>-rohan
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip> 



------_=_NextPart_001_01C0799E.3213B580
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>I 
think part of the problem is to agree on the requirements the method is to 
satisfy.&nbsp; On one side of the debate, we've had pressure to restrict REFER 
functionality to call transfer.&nbsp; On the other is Jonathan's vision of a set 
of general primitives.&nbsp; Thus to add to Rohan's valuable roundup of issues 
below, I add a list of alternative functional requirements.&nbsp; Just to make 
it clear that I have my own views on the matter, I list my preferred alternative 
first in each case.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=560280616-08012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>1) 
Relation to existing session</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(a) 
REFER can be sent independently of any existing session.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(b) 
REFER can only be sent on an already-existing call-leg.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(c) 
...</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=560280616-08012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>2) 
Method invoked by REFER</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(a) 
Any method can be invoked, including BYE.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(b) 
</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=560280616-08012001>REFER always asks the receiving party to send an 
INVITE.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(c) 
REFER-eligibility varies and must be documented on a per-method 
basis.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=560280616-08012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>3) 
Notification of results</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(a) 
REFER implicitly subscribes to SIP events at the receiver </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=560280616-08012001></SPAN></FONT><FONT color=#0000ff face=Arial 
size=2><SPAN class=560280616-08012001>(b) The referror must issue an explicit 
SUBS to get notification</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=560280616-08012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>4) 
Join vs. Replace vs. New</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(a) 
Explicit indication of intent in a header</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(b) 
...</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>Note 
that this is an issue for any receiver of an INVITE, not necessarily tied to 
REFER.&nbsp; As such, it is a matter for another thread, which I will 
initiate.</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma><FONT 
  size=2>-----Original Message-----<BR><B>From:</B> Rohan Mahy 
  [mailto:rohan@cisco.com]<BR><B>Sent:</B> Monday, January 08, 2001 11:20 
  AM<BR><B>To:</B> sip@lists.bell-labs.com<BR><B>Subject:</B> Re: [SIP] REFER 
  open issues<BR><BR></FONT></DIV>
  <DIV></FONT><SPAN class=560280616-08012001><FONT color=#0000ff face=Arial 
  size=2>&nbsp;<FONT color=#000000 face=Tahoma>[meeting&nbsp;proposal 
  snipped]</FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=560280616-08012001></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=560280616-08012001>&nbsp;</SPAN>At 10:08 AM 12/15/00 , Rohan 
  Mahy wrote:<BR>&gt;Hi,<BR>&gt;<BR>&gt;I'd like to summarize ALL the open 
  issues that we have with REFER.&nbsp; In the<BR>&gt;interest of coming to 
  consensus, I'd like to invite interested implementers<BR>&gt;who have comments 
  to meet in person before Minneapolis to close REFER open<BR>&gt;issues.&nbsp; 
  If folks think this is a good idea, we would certainly post the<BR>&gt;minutes 
  and partial consensus back to the list for comments/changes.&nbsp; As 
  a<BR>&gt;strawman, I will suggest sometime in the last week of January.&nbsp; 
  A few<BR>&gt;plausible locations are: Dallas, New York, San Jose...&nbsp; I 
  volunteer to<BR>&gt;organize this if necessary.<BR>&gt;<BR>&gt;A short summary 
  of the issues are below in no particular order:<BR>&gt;<BR>&gt;1) 
  Retransmission problem:<BR>&gt;Robert Sparks already summarized this problem 
  in his recent post.<BR>&gt;(a) REFER completes early, use explicit SUBSCRIBE 
  for more info<BR>&gt;(b) REFER completes early and implicitly SUBSCRIBEs to 
  more info<BR>&gt;(c) REFER completes after 16 secs and provides URL for 
  SUBSCRIBE<BR>&gt;(d) send new REFER (new CSeq same call ID) after 32 
  seconds.<BR>&gt;<BR>&gt;2) Cancellation:<BR>&gt;If REFER returns a final 
  response before a long INVITE transaction<BR>&gt;completes, how do you cancel 
  that INVITE?&nbsp; <BR>&gt;(a) send same REFER with ;method=CANCEL<BR>&gt;(b) 
  send REFERCANCEL method<BR>&gt;<BR>&gt;3) Call-leg matching:<BR>&gt;Should you 
  include call-id's in Refer-to URLs?&nbsp; If not, what do you use 
  for<BR>&gt;matching (Replaces or similar)?<BR>&gt;(a) match 
  call-ids<BR>&gt;(b) use a Replaces header<BR>&gt;(c) use the mesh-id to setup 
  mesh, then say BYE<BR>&gt;(d) use a new header<BR>&gt;<BR>&gt;4) If we choose 
  Replaces or the like, how do we express that we want to<BR>&gt;*join* 2 legs 
  via REFER?<BR>&gt;(a) Join header<BR>&gt;(b) Associate header<BR>&gt;(c) new 
  method<BR>&gt;(d) something else<BR>&gt;<BR>&gt;5) If Refer-To contains 
  parameters (method, transport), or potentially<BR>&gt;contradictory headers, 
  what do we do with them?<BR>&gt;(a) allow all of them if authorized<BR>&gt;(b) 
  allow a subset of methods/headers<BR>&gt;(c) send an error mesage<BR>&gt;(d) 
  ignore the headers/parameters<BR>&gt;(e) ignore the whole 
  message<BR>&gt;<BR>&gt;6) If we don't allow&nbsp; ;method=BYE, how do we solve 
  the problem described in<BR>&gt;the Music on <BR>&gt;Hold flow?<BR>&gt;(a) 
  method=BYE<BR>&gt;(b) ???<BR>&gt;<BR>&gt;7) How do we ask devices to do stuff 
  for us?&nbsp; [probably defer this issue]<BR>&gt;(a) REFER with 
  parameters/headers<BR>&gt;(b) PHONECTL<BR>&gt;(c) some NEWMETHOD<BR>&gt;(d) 
  Mbus<BR>&gt;(e) other<BR>&gt;<BR>&gt;Any other REFER open issues I 
  missed?<BR>&gt;<BR>&gt;thanks,<BR>&gt;-rohan<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;_______________________________________________<BR>&gt;SIP 
  mailing list<BR>&gt;SIP@lists.bell-labs.com<BR>&gt;<A 
  href="http://lists.bell-labs.com/mailman/listinfo/sip" 
  eudora="autourl">http://lists.bell-labs.com/mailman/listinfo/sip</A><BR></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C0799E.3213B580--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 07:57:34 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10187
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 07:57:34 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2CD7244389; Tue,  9 Jan 2001 06:55:11 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by lists.bell-labs.com (Postfix) with ESMTP id F25494433A
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 12:31:36 -0500 (EST)
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Mon, 8 Jan 2001 13:31:11 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBRCXZ>; Mon, 8 Jan 2001 13:31:13 -0500
Message-ID: <28560036253BD41191A10000F8BCBD11034745CC@zcard00g.ca.nortel.com>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@americasm01.nt.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C079A1.2C2B3AA0"
X-Orig: <taylor@americasm01.nt.com>
Subject: [SIP] Join vs. Replace vs. New
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 8 Jan 2001 13:31:10 -0500

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_01C079A1.2C2B3AA0
Content-Type: text/plain;
	charset="iso-8859-1"

The issue of how an invitee is expected to interpret an incoming invitation
has come up occasionally, usually in conjunction with a discussion of the
REFER method.  I would maintain that the two topics are actually
independent.

The basic problem is how the receiver of an initial INVITE can distinguish
between
 -- a new incoming call-leg, unrelated to others already in progress
 -- a call-leg intended to replace an existing call-leg
 -- a call-leg intended to join (i.e. operate simultaneously and in
interaction with) an existing call-leg.

We had some discussion of the significance of Call-Id and its possible use
for this purpose at the last meeting, but didn't come to any helpful
conclusion.  Biggs and Dean have defined the Replaces header in
draft-biggs-sip-replaces-00.txt, but this only solves part of the problem.
I suggest that we need a slight generalization of the Replaces header -- say
the Call-Intent: header, with one of its parameters indicating the intention
of the new leg.  Default in the absence of the header would be "new", to
provide equivalent to existing functionality.  The header could be present
in any initial INVITE.  We can think about whether it has uses beyond that,
say when someone wants to merge two independent calls into a single
conference.

Comments?  I'm prepared to do some writing as required to spell this out. 

Tom Taylor
Multimedia Control and Applications Standards
Ph.  +1 613 736 0961
Cell +1 613 290 0844
taylor@nortelnetworks.com 

------_=_NextPart_001_01C079A1.2C2B3AA0
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>Join vs. Replace vs. New</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>The issue of how an invitee is expected to interpret =
an incoming invitation has come up occasionally, usually in conjunction =
with a discussion of the REFER method.&nbsp; I would maintain that the =
two topics are actually independent.</FONT></P>

<P><FONT SIZE=3D2>The basic problem is how the receiver of an initial =
INVITE can distinguish between</FONT>
<BR><FONT SIZE=3D2>&nbsp;-- a new incoming call-leg, unrelated to =
others already in progress</FONT>
<BR><FONT SIZE=3D2>&nbsp;-- a call-leg intended to replace an existing =
call-leg</FONT>
<BR><FONT SIZE=3D2>&nbsp;-- a call-leg intended to join (i.e. operate =
simultaneously and in interaction with) an existing call-leg.</FONT>
</P>

<P><FONT SIZE=3D2>We had some discussion of the significance of Call-Id =
and its possible use for this purpose at the last meeting, but didn't =
come to any helpful conclusion.&nbsp; Biggs and Dean have defined the =
Replaces header in draft-biggs-sip-replaces-00.txt, but this only =
solves part of the problem.&nbsp; I suggest that we need a slight =
generalization of the Replaces header -- say the Call-Intent: header, =
with one of its parameters indicating the intention of the new =
leg.&nbsp; Default in the absence of the header would be =
&quot;new&quot;, to provide equivalent to existing functionality.&nbsp; =
The header could be present in any initial INVITE.&nbsp; We can think =
about whether it has uses beyond that, say when someone wants to merge =
two independent calls into a single conference.</FONT></P>

<P><FONT SIZE=3D2>Comments?&nbsp; I'm prepared to do some writing as =
required to spell this out. </FONT>
</P>

<P><FONT SIZE=3D2>Tom Taylor</FONT>
<BR><FONT SIZE=3D2>Multimedia Control and Applications Standards</FONT>
<BR><FONT SIZE=3D2>Ph.&nbsp; +1 613 736 0961</FONT>
<BR><FONT SIZE=3D2>Cell +1 613 290 0844</FONT>
<BR><FONT SIZE=3D2>taylor@nortelnetworks.com </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C079A1.2C2B3AA0--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 08:02:01 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10317
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 08:02:01 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4A2A54438E; Tue,  9 Jan 2001 06:55:19 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241])
	by lists.bell-labs.com (Postfix) with ESMTP id E1F2344337
	for <sip@lists.bell-labs.com>; Mon,  8 Jan 2001 14:03:54 -0500 (EST)
Received: from francislaptop ([208.176.6.221])
 by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9)
 with SMTP id <0G6V00HJC0RPA3@mta5.snfc21.pbi.net> for sip@lists.bell-labs.com;
 Mon,  8 Jan 2001 11:57:34 -0800 (PST)
From: Paul Francis <yoid2000@pacbell.net>
Subject: Re: [SIP] question on received tag in via
 header,draft-ietf-sip-rfc2543bis-02.txt
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
        Neil Deason <ndeason@ubiquity.net>
Cc: Jo Hornsby <jhornsby@ubiquity.net>, Paul Francis <paul@francis.com>,
        sip@lists.bell-labs.com
Reply-To: Paul Francis <paul@francis.com>
Message-id: <013b01c079ad$d19f1220$a7fb10ac@francislaptop>
MIME-version: 1.0
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
References: <000d01c0795a$880d1470$4e34c3c1@ubiquity.co.uk>
 <3A599F3C.16FBCE86@ubiquity.net> <3A5A040B.DFB38D19@cs.columbia.edu>
X-Priority: 3
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 08 Jan 2001 12:01:28 -0800
Content-Transfer-Encoding: 7bit


> Neil Deason wrote:
> >
> > Jo Hornsby wrote:
> > >
> > > > Why is it that the receiver tag in the via header indicate the
received
> > > > network address but not also the received port (in section 6.47.2
> > > > Receiver-tagged Via Header Fields)?
> > >
> > > In a nutshell: the port is generally not considered useful since
> > > just because a client sends from a particular port, it doesn't
> > > mean that it's also listening on that port.
> > >

Got it.  Thanks.

> > > (I vote that this becomes a FAQ.)
> >
> > I would further ask that we simply the SIP spec in this area.
> > 6.47.1 Requests (p.77) and 6.47.2 Receiver-tagged Via Header
> > Fields (p.78) both contain text about adding the received
> > parameter. In 6.47.2 this crops up in relation to NATs. As the
> > received param alone will not solve NAT issues can this
> > reference be removed and these two sections consolidated into
> > one?
>
> I've combined the material into 6.47.2 and made up a multi-homed example
> rather than a NAT example, removing mention of NATs altogether.

This strikes me as potentially not adequately addressing the issue, for two
reasons.

First, it seems to me that the received tag is is certainly useful for the
NAT case where there is no port translation, and so off hand seems to solve
the problem there.  This is an important case, so removing any discussion of
NAT seems a bad idea.

Second, it seems to me that if you really did not want to use this for any
kind of NAT, then I would question whether it would be better to remove the
received tag altogether, on the basis that the multihomed case is such a
corner case that it isn't worth putting the tag in the via header.  The
reasoning here is that the SIP implementation can certainly arrange to know
what the source address on the IP packet is going to be, so it can also
arrange to put the same address in the SIP header.  The corner case is
where, for some reason, the host wants to send packets out via one IP
address, and then receive them via another IP address, and I don't think
this needs solving for.

So assuming that we still want to be able to solve for at least the NAT with
no port translation case, I think the original NAT example makes sense.
What is needed is either:

1.  Text describing the NAT case that isn't solved (i.e., port translation
where the port used to send the packet is not the same as the listen
port...by the way, is this a common scenario?), or
2.  Actually make an effort to solve even for the case of NAT port
translation.  This would take some thought, but I guess it would require
something where the sending host indicates in the via header what source
port its outgoing packet used, and the receiving host detecting that the
port has changed, and further noting that if the source port is not the same
as the listen port, to do some kind of error because it isn't going to be
able to return a packet anyway...

PF



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 08:05:47 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10441
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 08:05:46 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 96EA544398; Tue,  9 Jan 2001 07:01:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by lists.bell-labs.com (Postfix) with ESMTP id F22F24437D
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 07:00:43 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA07097;
	Tue, 9 Jan 2001 08:00:30 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA01174;
	Tue, 9 Jan 2001 08:00:32 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <CRQSKY6R>; Tue, 9 Jan 2001 08:00:31 -0500
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EC9B@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        "'Rohan Mahy'" <rohan@cisco.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] REFER open issues
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C07A3C.2522ADB0"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 08:00:30 -0500

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_01C07A3C.2522ADB0
Content-Type: text/plain;
	charset="iso-8859-1"

Depends on the players.
 
If the same folks need to solve multiple problems, then Jonathan is right.
If the cast
of characters changes, than single purpose meetings work.  I suspect the
same folks
need to be at most if not all these meetings, and thus we need to have a
(small)
set of problems to solve.
 
I don't want to spoil Rohan's initiative however.  So, let's 
        Respond to his request
        Make a (small) list of other topics to cover
 
Brian

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Tuesday, January 09, 2001 2:35 AM
To: 'Rohan Mahy'; sip@lists.bell-labs.com
Subject: RE: [SIP] REFER open issues


I don't want to have an interim meeting JUST on REFER. There are lots of
other open issues. We should seek to accomplish as much as possible in one
meeting, rather than having meetings for each issue. 
 
-Jonathan R.
 

Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen <http://www.cs.columbia.edu/~jdrosen>
PHONE: (973) 952-5000
http://www.dynamicsoft.com <http://www.dynamicsoft.com/> 
  

-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Monday, January 08, 2001 11:20 AM
To: sip@lists.bell-labs.com
Subject: Re: [SIP] REFER open issues


Hi,

I've heard some mixed interest at the IETF, and no objections to an interim
meeting to build some consensus around REFER open issues.  If you are
intersted in attending a meeting **and have posted to the list on one of
these REFER-related topics**, please indicate your availability and ability
to travel to some sample US destinations the last week of January/first week
of February by filling in the grid below.  an [x] means you are available, a
[?] is a maybe.

Of course all the meeting minutes, proposals, etc will get posted back to
this list.
Again, please do not spam the whole list with your availability.  I'll post
a summary.

        Please use a fixed-width font such as Courier.

        Available    San Jose   Dallas   New York  RaleighNC  Other

Jan 29    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
    30    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
    31    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
Feb  1    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
     2    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]

     5    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
     6    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
     7    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
     8    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
     9    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]


thanks,
-rohan


At 10:08 AM 12/15/00 , Rohan Mahy wrote:
>Hi,
>
>I'd like to summarize ALL the open issues that we have with REFER.  In the
>interest of coming to consensus, I'd like to invite interested implementers
>who have comments to meet in person before Minneapolis to close REFER open
>issues.  If folks think this is a good idea, we would certainly post the
>minutes and partial consensus back to the list for comments/changes.  As a
>strawman, I will suggest sometime in the last week of January.  A few
>plausible locations are: Dallas, New York, San Jose...  I volunteer to
>organize this if necessary.
>
>A short summary of the issues are below in no particular order:
>
>1) Retransmission problem:
>Robert Sparks already summarized this problem in his recent post.
>(a) REFER completes early, use explicit SUBSCRIBE for more info
>(b) REFER completes early and implicitly SUBSCRIBEs to more info
>(c) REFER completes after 16 secs and provides URL for SUBSCRIBE
>(d) send new REFER (new CSeq same call ID) after 32 seconds.
>
>2) Cancellation:
>If REFER returns a final response before a long INVITE transaction
>completes, how do you cancel that INVITE?  
>(a) send same REFER with ;method=CANCEL
>(b) send REFERCANCEL method
>
>3) Call-leg matching:
>Should you include call-id's in Refer-to URLs?  If not, what do you use for
>matching (Replaces or similar)?
>(a) match call-ids
>(b) use a Replaces header
>(c) use the mesh-id to setup mesh, then say BYE
>(d) use a new header
>
>4) If we choose Replaces or the like, how do we express that we want to
>*join* 2 legs via REFER?
>(a) Join header
>(b) Associate header
>(c) new method
>(d) something else
>
>5) If Refer-To contains parameters (method, transport), or potentially
>contradictory headers, what do we do with them?
>(a) allow all of them if authorized
>(b) allow a subset of methods/headers
>(c) send an error mesage
>(d) ignore the headers/parameters
>(e) ignore the whole message
>
>6) If we don't allow  ;method=BYE, how do we solve the problem described in
>the Music on 
>Hold flow?
>(a) method=BYE
>(b) ???
>
>7) How do we ask devices to do stuff for us?  [probably defer this issue]
>(a) REFER with parameters/headers
>(b) PHONECTL
>(c) some NEWMETHOD
>(d) Mbus
>(e) other
>
>Any other REFER open issues I missed?
>
>thanks,
>-rohan
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip> 



------_=_NextPart_001_01C07A3C.2522ADB0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.50.4207.2601" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D461255712-09012001><FONT face=3DArial =
color=3D#0000ff>Depends on=20
the players.</FONT></SPAN></DIV>
<DIV><SPAN class=3D461255712-09012001><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D461255712-09012001><FONT face=3DArial =
color=3D#0000ff>If the same=20
folks need to solve multiple problems, then Jonathan is right.&nbsp; If =
the=20
cast</FONT></SPAN></DIV>
<DIV><SPAN class=3D461255712-09012001><FONT face=3DArial =
color=3D#0000ff>of characters=20
changes, than single purpose meetings work.&nbsp; I suspect the same=20
folks</FONT></SPAN></DIV>
<DIV><SPAN class=3D461255712-09012001><FONT face=3DArial =
color=3D#0000ff>need to be at=20
most if not all these meetings, and thus we need to have a=20
(small)</FONT></SPAN></DIV>
<DIV><SPAN class=3D461255712-09012001><FONT face=3DArial =
color=3D#0000ff>set of=20
problems to solve.</FONT></SPAN></DIV>
<DIV><SPAN class=3D461255712-09012001><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D461255712-09012001><FONT face=3DArial =
color=3D#0000ff>I don't want=20
to spoil Rohan's initiative however.&nbsp; So, let's =
</FONT></SPAN></DIV>
<DIV><SPAN =
class=3D461255712-09012001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<FONT face=3DArial color=3D#0000ff>Respond to his =
request</FONT></SPAN></DIV>
<DIV><SPAN =
class=3D461255712-09012001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<FONT face=3DArial color=3D#0000ff>Make a (small) list of other topics =
to=20
cover</FONT></SPAN></DIV>
<DIV><SPAN class=3D461255712-09012001><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D461255712-09012001><FONT face=3DArial=20
color=3D#0000ff>Brian</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Jonathan =
Rosenberg=20
  [mailto:jdrosen@dynamicsoft.com]<BR><B>Sent:</B> Tuesday, January 09, =
2001=20
  2:35 AM<BR><B>To:</B> 'Rohan Mahy'; =
sip@lists.bell-labs.com<BR><B>Subject:</B>=20
  RE: [SIP] REFER open issues<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D251493307-09012001><FONT face=3D"Courier New" =
color=3D#0000ff=20
  size=3D2>I don't want to have an interim meeting JUST on REFER. There =
are lots=20
  of other open issues. We should seek to accomplish as much as =
possible in one=20
  meeting, rather than having meetings for each issue. =
</FONT></SPAN></DIV>
  <DIV><SPAN class=3D251493307-09012001><FONT face=3D"Courier New" =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D251493307-09012001><FONT face=3D"Courier New" =
color=3D#0000ff=20
  size=3D2>-Jonathan R.</FONT></SPAN></DIV>
  <DIV>&nbsp;</DIV>
  <P><FONT size=3D2>Jonathan D.=20
  =
Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  72 Eagle Rock Ave.<BR>Chief=20
  =
Scientist&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  First=20
  =
Floor<BR>dynamicsoft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  East Hanover, NJ=20
  =
07936<BR>jdrosen@dynamicsoft.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
  FAX:&nbsp;&nbsp; (973) 952-5050<BR><A target=3D_blank=20
  =
href=3D"http://www.cs.columbia.edu/~jdrosen">http://www.cs.columbia.edu/=
~jdrosen</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  PHONE: (973) 952-5000<BR><A target=3D_blank=20
  =
href=3D"http://www.dynamicsoft.com/">http://www.dynamicsoft.com</A><BR>&=
nbsp;</FONT>=20
  </P>
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Rohan Mahy=20
    [mailto:rohan@cisco.com]<BR><B>Sent:</B> Monday, January 08, 2001 =
11:20=20
    AM<BR><B>To:</B> sip@lists.bell-labs.com<BR><B>Subject:</B> Re: =
[SIP] REFER=20
    open issues<BR><BR></FONT></DIV>Hi,<BR><BR>I've heard some mixed =
interest at=20
    the IETF, and no objections to an interim meeting to build some =
consensus=20
    around REFER open issues.&nbsp; If you are intersted in attending a =
meeting=20
    **and have posted to the list on one of these REFER-related =
topics**, please=20
    indicate your availability and ability to travel to some sample US=20
    destinations the last week of January/first week of February by =
filling in=20
    the grid below.&nbsp; an [x] means you are available, a [?] is a=20
    maybe.<BR><BR>Of course all the meeting minutes, proposals, etc =
will get=20
    posted back to this list.<BR>Again, please do not spam the whole =
list with=20
    your availability.&nbsp; I'll post a summary.<BR><BR><FONT=20
    face=3D"Courier, =
Courier">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Please=20
    use a fixed-width font such as=20
    Courier.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Available&nbsp;&nbsp;&nbsp; San Jose&nbsp;&nbsp; Dallas&nbsp;&nbsp; =
New=20
    York&nbsp; RaleighNC&nbsp; Other<BR><BR>Jan 29&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]<BR>&nbsp;&nbsp;&nbsp; 30&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]<BR>&nbsp;&nbsp;&nbsp; 31&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]<BR>Feb&nbsp; 1&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]<BR>&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp; 5&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]<BR>&nbsp;&nbsp;&nbsp;&nbsp; 6&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]<BR>&nbsp;&nbsp;&nbsp;&nbsp; 7&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]<BR>&nbsp;&nbsp;&nbsp;&nbsp; 8&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]<BR>&nbsp;&nbsp;&nbsp;&nbsp; 9&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [ =
]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=20
    ]<BR><BR><BR></FONT>thanks,<BR>-rohan<BR><BR><BR>At 10:08 AM =
12/15/00 ,=20
    Rohan Mahy wrote:<BR>&gt;Hi,<BR>&gt;<BR>&gt;I'd like to summarize =
ALL the=20
    open issues that we have with REFER.&nbsp; In the<BR>&gt;interest =
of coming=20
    to consensus, I'd like to invite interested implementers<BR>&gt;who =
have=20
    comments to meet in person before Minneapolis to close REFER=20
    open<BR>&gt;issues.&nbsp; If folks think this is a good idea, we =
would=20
    certainly post the<BR>&gt;minutes and partial consensus back to the =
list for=20
    comments/changes.&nbsp; As a<BR>&gt;strawman, I will suggest =
sometime in the=20
    last week of January.&nbsp; A few<BR>&gt;plausible locations are: =
Dallas,=20
    New York, San Jose...&nbsp; I volunteer to<BR>&gt;organize this if=20
    necessary.<BR>&gt;<BR>&gt;A short summary of the issues are below =
in no=20
    particular order:<BR>&gt;<BR>&gt;1) Retransmission =
problem:<BR>&gt;Robert=20
    Sparks already summarized this problem in his recent =
post.<BR>&gt;(a) REFER=20
    completes early, use explicit SUBSCRIBE for more info<BR>&gt;(b) =
REFER=20
    completes early and implicitly SUBSCRIBEs to more info<BR>&gt;(c) =
REFER=20
    completes after 16 secs and provides URL for SUBSCRIBE<BR>&gt;(d) =
send new=20
    REFER (new CSeq same call ID) after 32 seconds.<BR>&gt;<BR>&gt;2)=20
    Cancellation:<BR>&gt;If REFER returns a final response before a =
long INVITE=20
    transaction<BR>&gt;completes, how do you cancel that INVITE?&nbsp;=20
    <BR>&gt;(a) send same REFER with ;method=3DCANCEL<BR>&gt;(b) send =
REFERCANCEL=20
    method<BR>&gt;<BR>&gt;3) Call-leg matching:<BR>&gt;Should you =
include=20
    call-id's in Refer-to URLs?&nbsp; If not, what do you use=20
    for<BR>&gt;matching (Replaces or similar)?<BR>&gt;(a) match=20
    call-ids<BR>&gt;(b) use a Replaces header<BR>&gt;(c) use the =
mesh-id to=20
    setup mesh, then say BYE<BR>&gt;(d) use a new =
header<BR>&gt;<BR>&gt;4) If we=20
    choose Replaces or the like, how do we express that we want =
to<BR>&gt;*join*=20
    2 legs via REFER?<BR>&gt;(a) Join header<BR>&gt;(b) Associate=20
    header<BR>&gt;(c) new method<BR>&gt;(d) something =
else<BR>&gt;<BR>&gt;5) If=20
    Refer-To contains parameters (method, transport), or=20
    potentially<BR>&gt;contradictory headers, what do we do with=20
    them?<BR>&gt;(a) allow all of them if authorized<BR>&gt;(b) allow a =
subset=20
    of methods/headers<BR>&gt;(c) send an error mesage<BR>&gt;(d) =
ignore the=20
    headers/parameters<BR>&gt;(e) ignore the whole =
message<BR>&gt;<BR>&gt;6) If=20
    we don't allow&nbsp; ;method=3DBYE, how do we solve the problem =
described=20
    in<BR>&gt;the Music on <BR>&gt;Hold flow?<BR>&gt;(a) =
method=3DBYE<BR>&gt;(b)=20
    ???<BR>&gt;<BR>&gt;7) How do we ask devices to do stuff for =
us?&nbsp;=20
    [probably defer this issue]<BR>&gt;(a) REFER with=20
    parameters/headers<BR>&gt;(b) PHONECTL<BR>&gt;(c) some =
NEWMETHOD<BR>&gt;(d)=20
    Mbus<BR>&gt;(e) other<BR>&gt;<BR>&gt;Any other REFER open issues I=20
    =
missed?<BR>&gt;<BR>&gt;thanks,<BR>&gt;-rohan<BR>&gt;<BR>&gt;<BR>&gt;<BR>=
&gt;_______________________________________________<BR>&gt;SIP=20
    mailing list<BR>&gt;SIP@lists.bell-labs.com<BR>&gt;<A=20
    href=3D"http://lists.bell-labs.com/mailman/listinfo/sip"=20
    =
eudora=3D"autourl">http://lists.bell-labs.com/mailman/listinfo/sip</A><B=
R></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C07A3C.2522ADB0--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 08:11:47 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10592
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 08:11:47 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 449074439C; Tue,  9 Jan 2001 07:08:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by lists.bell-labs.com (Postfix) with ESMTP id 4971A44396
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 07:07:00 -0500 (EST)
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f09D6c310056
	for <sip@lists.bell-labs.com>; Tue, 9 Jan 2001 15:06:38 +0200 (EET)
Received: from esebh02nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.1.2) with ESMTP id <Bac158f23510080e93e@esvir03nok.nokia.com>;
 Tue, 9 Jan 2001 15:06:39 +0200
Received: by esebh02nok with Internet Mail Service (5.5.2652.78)
	id <Z1JDPGG0>; Tue, 9 Jan 2001 15:06:25 +0200
Message-ID: <EF9802A00654D411934E00508BAD76CC1000BE@eseis13nok.ntc.nokia.com>
From: aki.niemi@nokia.com
To: sip@lists.bell-labs.com
Cc: jdrosen@dynamicsoft.com
Subject: RE: [SIP] SIP grammar doubt.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 15:06:24 +0200


> 
> A generalization is that the structure of the header is:
> 
> Authorization = "Authorization" ":" mechanisms 1#mech-params
> mechanisms = "pgp" | "Basic" | "Digest" | token
> mech-params = digest-response | basic-response | pgp-response
> 
> 
> Note, however, that we are going to deprecate PGP stuff. It will be
> superceded by S/MIME and PGP MIME.

A question concerning this, is there any work ongoing in this field? Any
drafts about S/MIME and MIME PGP usage in SIP on the way? 

Cheers,
Aki Niemi

> 
> -Jonathan R.
> 
> 
> 
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 08:33:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10994
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 08:33:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A2B584434B; Tue,  9 Jan 2001 07:34:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id 63C734434B
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 07:33:41 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 9 Jan 2001 13:33:30 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id NAA08936; Tue, 9 Jan 2001 13:32:10 GMT
Message-ID: <3A5B12DA.F2123C03@ubiquity.net>
From: Neil Deason <ndeason@ubiquity.net>
Organization: Ubiquity Software Corporation Limited
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Francis <paul@francis.com>
Cc: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
        Jo Hornsby <jhornsby@ubiquity.net>, sip@lists.bell-labs.com
Subject: Re: [SIP] question on received tag in 
 viaheader,draft-ietf-sip-rfc2543bis-02.txt
References: <000d01c0795a$880d1470$4e34c3c1@ubiquity.co.uk>
	 <3A599F3C.16FBCE86@ubiquity.net> <3A5A040B.DFB38D19@cs.columbia.edu> <013b01c079ad$d19f1220$a7fb10ac@francislaptop>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 13:32:10 +0000
Content-Transfer-Encoding: 7bit

Paul Francis wrote:
> 
> > Neil Deason wrote:
> > >
> > > Jo Hornsby wrote:
> > > >
> > > > > Why is it that the receiver tag in the via header indicate the
> received
> > > > > network address but not also the received port (in section 6.47.2
> > > > > Receiver-tagged Via Header Fields)?
> > > >
> > > > In a nutshell: the port is generally not considered useful since
> > > > just because a client sends from a particular port, it doesn't
> > > > mean that it's also listening on that port.
> > > >
> 
> Got it.  Thanks.
> 
> > > > (I vote that this becomes a FAQ.)
> > >
> > > I would further ask that we simply the SIP spec in this area.
> > > 6.47.1 Requests (p.77) and 6.47.2 Receiver-tagged Via Header
> > > Fields (p.78) both contain text about adding the received
> > > parameter. In 6.47.2 this crops up in relation to NATs. As the
> > > received param alone will not solve NAT issues can this
> > > reference be removed and these two sections consolidated into
> > > one?
> >
> > I've combined the material into 6.47.2 and made up a multi-homed example
> > rather than a NAT example, removing mention of NATs altogether.
> 
> This strikes me as potentially not adequately addressing the issue, for two
> reasons.
> 
> First, it seems to me that the received tag is is certainly useful for the
> NAT case where there is no port translation, and so off hand seems to solve
> the problem there.  This is an important case, so removing any discussion of
> NAT seems a bad idea.

Mentioning the word NAT is unhelpful there because the 
following text is not a complete solution. This causes
confusion and questions like your own.

> Second, it seems to me that if you really did not want to use this for any
> kind of NAT, then I would question whether it would be better to remove the
> received tag altogether, on the basis that the multihomed case is such a
> corner case that it isn't worth putting the tag in the via header.  The
> reasoning here is that the SIP implementation can certainly arrange to know
> what the source address on the IP packet is going to be, so it can also
> arrange to put the same address in the SIP header. 

You cannot guarantee that every SIP implementation will 
in fact know this. So it makes the protocol more robust for
the receiving party to check what happened than rely on 
the sender to set things up right.

> The corner case is
> where, for some reason, the host wants to send packets out via one IP
> address, and then receive them via another IP address, and I don't think
> this needs solving for.
> 
> So assuming that we still want to be able to solve for at least the NAT with
> no port translation case, I think the original NAT example makes sense.
> What is needed is either:
> 
> 1.  Text describing the NAT case that isn't solved (i.e., port translation
> where the port used to send the packet is not the same as the listen
> port...by the way, is this a common scenario?), or
> 2.  Actually make an effort to solve even for the case of NAT port
> translation.  This would take some thought, but I guess it would require
> something where the sending host indicates in the via header what source
> port its outgoing packet used, and the receiving host detecting that the
> port has changed, and further noting that if the source port is not the same
> as the listen port, to do some kind of error because it isn't going to be
> able to return a packet anyway...

NAT/Firewall issues need to be addressed but not within 
the confines of the core spec where we need to be looking 
for what can be taken out not added. There are already drafts 
on the subject hopefully something will arise out of them.

Cheers,
Neil
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 08:45:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11428
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 08:45:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 06A0744388; Tue,  9 Jan 2001 07:46:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61])
	by lists.bell-labs.com (Postfix) with ESMTP id 4640E44337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 07:45:43 -0500 (EST)
Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc363f43d5100368f7c@cvis29.marconicomms.com> for <sip@lists.bell-labs.com>;
 Tue, 9 Jan 2001 13:45:26 +0000
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-30) id NAA06427; Tue, 9 Jan 2001 13:45:26 GMT
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 802569CF.004B8578 ; Tue, 9 Jan 2001 13:44:53 +0000
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Keith Robinson" <Keith.Robinson@marconi.com>
To: sip@lists.bell-labs.com
Message-ID: <802569CF.004B8238.00@marconicomms.com>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] Question regarding Call-Id and call leg identification
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 13:44:56 +0000




---------------------- Forwarded by Keith Robinson/MAIN/MC1 on 09/01/2001 13:43
---------------------------


09/01/2001 13:34
Keith Robinson


Regarding section 11.5 of RFC2543bis02, what is the meaning of the request  if,
having got
to (3), neither the To or From fields match any stored values for the received
Call-Id, i.e., we
have received an existing Call-Id with new To and/or From
fields. Is it a request to set up a new call leg on this Call-Id or is it an
erroneous request ?

Regards,

K. Robinson




_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 08:55:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11736
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 08:55:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 321B744388; Tue,  9 Jan 2001 07:56:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id CAE2344382
	for <SIP@lists.bell-labs.com>; Tue,  9 Jan 2001 07:55:49 -0500 (EST)
Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f09DtWd21968;
	Tue, 9 Jan 2001 14:55:32 +0100 (MET)
Received: from uabx04c384.uab.ericsson.se..uab.ericsson.se (uabx04c384 [134.138.229.144])
	by ms.uab.ericsson.se (8.11.1/8.11.1/uab-3.3) with ESMTP id f09DtVC21746;
	Tue, 9 Jan 2001 14:55:31 +0100 (MET)
Received: from uab.ericsson.se by uabx04c384.uab.ericsson.se..uab.ericsson.se (8.8.7/client-1.3uab1)
	id OAA08639; Tue, 9 Jan 2001 14:55:30 +0100 (MET)
Message-ID: <3A5B1851.C9CB30F7@uab.ericsson.se>
From: Bertil Engelholm <Bertil.Engelholm@uab.ericsson.se>
Organization: Ericsson Utvecklings AB
X-Mailer: Mozilla 4.76C-CCK-MCD  [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: sv,en-US
MIME-Version: 1.0
To: Jo Hornsby <jhornsby@ubiquity.net>
Cc: SIP@lists.bell-labs.com
Subject: Re: [SIP] CANCEL problem ??
References: <001201c07a3a$6be3ffd0$4e34c3c1@ubiquity.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 14:55:29 +0100
Content-Transfer-Encoding: 7bit

Jo Hornsby wrote:
> 
> Almost.  The proxy should do as you say; however, it should
> not send the 487; rather, it should wait for responses on
> all branches as it normally would do.
> 
> There is an issue here, however, if a proxy happens to have
> an "older" (i.e., non-487 aware) server at the end of one of
> its branches.  In this case, it will probably not get a final
> response to the INVITE (or whatever).  A solution to this is
> to start a timer when a CANCEL has been issued, and if this
> timer expires, then "imagine" that you got a 487 along that
> branch.
> 
> The difficulty is what value to use for the timer.  There
> was some discussion about this a while back. Have a look at
> the thread entitled:
> "CANCEL - response sequence issue (again)"
> (it was mid-late October).
> 

OK, I have read the thread and I think I understand better know.
I thought that the 200 response to CANCEL meant that the CANCEL
was executed OK. From what you are saying and the above thread
I get the impression that the 200 OK to CANCEL is just a 
confirmation that you have received the CANCEL request. It's 
the final response to the original request that tells you if 
the cancelling actually was done or not. 
Is this correct understood ?

/Bertil 

-- 
Bertil Engelholm
AXE Research and Development        voice : +46 8 727 3499
SIP Security                        Fax   : +46 8 647 8276
S-126 25 Stockholm Sweden           E-mail:
Bertil.Engelholm@uab.ericsson.se

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 11:08:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14917
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 11:08:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 34A124433C; Tue,  9 Jan 2001 10:09:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 927F544337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 10:08:05 -0500 (EST)
Received: from CINQUECENTO ([63.110.3.212])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id LAA20356
	for <sip@lists.bell-labs.com>; Tue, 9 Jan 2001 11:10:39 -0500 (EST)
From: "Robert Sparks" <rsparks@dynamicsoft.com>
To: <sip@lists.bell-labs.com>
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30474A5@DYN-TX-EXCH-001.dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <3A5B12DA.F2123C03@ubiquity.net>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Subject: [SIP] REFER progress
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 09:29:30 -0600
Content-Transfer-Encoding: 7bit

a.s. This got a little long - sorry
     It does contain a concrete proposal.
------------
I think we are falling into a set of traps
with the REFER discussions, endangering an
already overdue deliverable.

The worst is specification creep. The group
was pretty happy with the functionality of
the current draft. When we tripped up on the
timeout problem, we saw a host of extra 
functionality we could add while working
around that problem.

Most of us have gravitated towards a model
where REFER is answered with a set of
reciprocal responses (essentially NOTIFYs,
possibly of a different name, with or without
an explicit subscribe). What we _haven't_
spent much time on is the profile of those
responses. How many can there be? What do
they contain?

I really anticipate the answers to those last
questions will vary widely depending on the
application using REFER. We want to be able
to do other things than transfer (this is 
why the method got renamed from TRANSFER).
A rich response set for a REFER that triggers
a SUBSCRIBE is likely to be entirely different
in character from one that triggers an INVITE.


PROPOSAL
In interests of meeting our working group
deliverable on this topic (now _WAY_ overdue),
I suggest that obtaining this rich response
set has shown itself to be too big a bite. I
propose that it is time to fall back to a single
REFERDONE reciprocal request, carrying the
information that is provided in the current
draft's final response. This would provide a
baseline version of REFER that would meet the
requirements the current draft addresses.

I further propose that when we complete that work,
we can return to REFER and define an extension that
would get the richer response set, addressing the
current lack of definition of that response set
with something like sip-event profiles.

RjS



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 11:21:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15309
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 11:21:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0B3344436B; Tue,  9 Jan 2001 10:22:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 7FFF744353
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 10:21:47 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f09GLKt21298;
	Tue, 9 Jan 2001 10:21:20 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Early media replacement.
Message-ID: <20010109102000.B27141@fdd.com>
References: <B65B4F8437968F488A01A940B21982BF9AB016@DYN-EXCH-001.dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <B65B4F8437968F488A01A940B21982BF9AB016@DYN-EXCH-001.dynamicsoft.com>; from jdrosen@dynamicsoft.com on Tue, Jan 09, 2001 at 01:25:41AM -0500
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 10:20:00 -0600

On Tue, Jan 09, 2001 at 01:25:41AM -0500, Jonathan Rosenberg wrote:
> In practice, I doubt calls to PSTN numbers will fork anyway. 

Then why do you oppose me?  

> That aside, a UA can deal with the multiplicity of streams in the
> standard RTP way - sort them out by SSRC, and play one and/or mix
> them as it sees fit. It needs to be able to do that whether or not
> the 183 message is present. 
> 
> > Early media doesn't help.  Let's kill it.
> 
> I'm afraid that this will simply not fly. 
> Gateways will, far too often, need to send
> media in the reverse direction without knowing
> what it is. The reality is that forking will be 
> problematic for PSTN interworking.
> Thats a reality of PSTN interoperability.
> Whining about it will not cause the problem to go 
> away. 
> 
> I am unwilling to dismiss PSTN interoperability as 
> an important issue for SIP. My hope is to allow a 
> normal SIP UA phone or PC client to not have to
> worry too much about it. The proposed solution
> of receiving media after INVITE (with the caveat that
> your RTP implementation needs to be correct and sort
> by SSRC any media that comes), alleviates any complex
> work on the side of a UA, and still pretty much
> works.
> 
> -Jonathan R.
> 

PSTN interoperability is paramount to me.  
Unfortunately, my calls need to work better 
than 99% of the time.  

If gateways "need to send media 
in the reverse direction without knowing what 
it is", then they should send a 200 OK because
the forking won't work anyway.  Why else
should early media persist if not for
forking?   Hopefully, the gateway builders will 
do the right thing.

I suppose I could omit SDP from my INVITES
and wait for the ACK so gateways have to
send me the 200 OK.  

Let's depreciate early media.

--
Rick



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 11:37:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15786
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 11:37:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3E1B144338; Tue,  9 Jan 2001 10:38:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by lists.bell-labs.com (Postfix) with ESMTP id D540444337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 10:37:28 -0500 (EST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 9 Jan 2001 08:36:21 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 09 Jan 2001 08:36:56 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532);
	 Tue, 9 Jan 2001 08:36:58 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0
content-class: urn:content-classes:message
Subject: RE: [SIP] new record-route text!
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9EC@speak.dogfood>
Thread-Topic: [SIP] new record-route text!
Thread-Index: AcB6IwMxuuZMCXnNSRSplpkYBXhgpAANVkyQ
From: "Christian Huitema" <huitema@exchange.microsoft.com>
To: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>,
        "Michael Thomas" <mat@cisco.com>
Cc: "Henning Schulzrinne" <hgs@cs.columbia.edu>, <sip@lists.bell-labs.com>
X-OriginalArrivalTime: 09 Jan 2001 16:36:58.0245 (UTC) FILETIME=[625F9350:01C07A5A]
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 08:36:55 -0800
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA15786


> Record routing is the ultimate in flexibility. A proxy that 
> doesn't need to
> be in the call path can get out of the way, and one which 
> needs to be in the
> call path to serve a useful function, can. It allows people 
> to build sip
> networks of all different flavors, and have them work with 
> the same UA.

Jonathan,

What you are describing are servers that essentially place themselves
in the middle of a call and want to keep a copy of the call state. In 
my mind, there is no difference between that and a "back-to-back UA"
implementation. The complexity of such systems derives from their
desire of being stateful "per call" (as opposed to stateful per 
transaction.) I would argue that the proposed record-route extension
only makes such servers marginally easier to write; in fact, in may make
them more complex, since it makes the whole protocol more complex.

The discussion has shown that we don't actually need this functionality
for the basic firewall case. In this case, we need to configure the UA
with
the coordinates of the proxy controlling the outgoing calls from the 
firewalled domain; the recording of a route is pretty much implicit. The

discussion has also outlined that the proxies cannot in any case rely 
entirely on the record-route feature, since UAs may always drop out
silently; any proxy that keep call state must have some way to clean
out the state on timeout, or maybe by detecting the loss of the medias.

I would not object all that much if the specification did not preclude
bypass of the recorded route, e.g. by issuing a re-invite to the 
contact address through an entirely new path. This would allow the
conversation to be redirected to a more direct path, or to a path
that is less dependent of the initial set of proxies. Come to think of 
it, there is no way to prevent UAs to do just that, which means that we
should not specify the impossible.

-- Christian Huitema

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 12:10:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17102
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 12:10:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BC7A144338; Tue,  9 Jan 2001 11:11:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 816D644337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 11:10:17 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f09H99x09674;
	Tue, 9 Jan 2001 11:09:09 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Early media replacement.
Message-ID: <20010109110903.C27141@fdd.com>
References: <E79883AEA37FD411A58C00508BAC5F4B2B5C30@exchange1.nuera.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <E79883AEA37FD411A58C00508BAC5F4B2B5C30@exchange1.nuera.com>; from rfairlie@nuera.com on Mon, Jan 08, 2001 at 11:44:20PM -0800
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 11:09:03 -0600

On Mon, Jan 08, 2001 at 11:44:20PM -0800, Fairlie-Cuninghame, Robert wrote:
> 
> I'm not sure about this. I imagine a common forking cases would a simple
> "helpdesk" style attendant pool. Where one helpdesk INVITE request is forked
> to a pool of attendents/extensions and the first to answer is connected. An
> attendent may have either registered a PSTN/PBX extension to the proxy or
> they may have forwarded their SIP phone to a PSTN number (mobile phone?) at
> their local proxy. In this case, the proxy will either not know about the
> PSTN endpoint or will not be able to do anything about it (ie, must still
> fork).
> 

Excellent example.  

Unfortunately, with this design the phone is going to be 
flooded with media from like ten streams.  If the
media is going to be ignored anyway, then why
not have the gateways hide it and send 180.
Should the forking proxy have muted the SDP?

I do not have a good solution for this example.

--
Rick
rick_dean@3com.com


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 12:15:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17318
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 12:15:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 668E544366; Tue,  9 Jan 2001 11:16:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 3FB9B44361
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 11:15:44 -0500 (EST)
Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f09HFTK23532;
	Tue, 9 Jan 2001 11:15:29 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f09HFTY12887;
	Tue, 9 Jan 2001 11:15:29 -0600 (CST)
Received: from ericsson.com (pc050184.exu.ericsson.se [138.85.50.184]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA24005; Tue, 9 Jan 2001 11:15:29 -0600 (CST)
Message-ID: <3A5B4740.2090307@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Sparks <rsparks@dynamicsoft.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] REFER progress
References: <9BF66EBF6BEFD942915B4D4D45C051F30474A5@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 11:15:44 -0600
Content-Transfer-Encoding: 7bit

I'm sorry, I don't see the standardization of the
REFERDONE as being any easier than the standardization
of a NOTIFY to serve the same purpose.

To satisfy a need stated by Billy, the
body of the NOTIFY could simply be the SDP
from the 200 OK (assuming an INVITE) or empty
for a BYE. Uses of REFER for other methods would
need to be specified in extension drafts.
The Event: token could be "referdone".

Is there anything else that needs to be specified
for the use of NOTIFY that I am missing?

I don't wish to drag this out forever. I think
the solution is fairly simple and straightforward
and could be extended in the future.

Please point out faults with this proposal and
areas of implementation difficulty.
/sean

Robert Sparks wrote:

> a.s. This got a little long - sorry
>      It does contain a concrete proposal.
> ------------
> I think we are falling into a set of traps
> with the REFER discussions, endangering an
> already overdue deliverable.
> 
> The worst is specification creep. The group
> was pretty happy with the functionality of
> the current draft. When we tripped up on the
> timeout problem, we saw a host of extra 
> functionality we could add while working
> around that problem.
> 
> Most of us have gravitated towards a model
> where REFER is answered with a set of
> reciprocal responses (essentially NOTIFYs,
> possibly of a different name, with or without
> an explicit subscribe). What we _haven't_
> spent much time on is the profile of those
> responses. How many can there be? What do
> they contain?
> 
> I really anticipate the answers to those last
> questions will vary widely depending on the
> application using REFER. We want to be able
> to do other things than transfer (this is 
> why the method got renamed from TRANSFER).
> A rich response set for a REFER that triggers
> a SUBSCRIBE is likely to be entirely different
> in character from one that triggers an INVITE.
> 
> 
> PROPOSAL
> In interests of meeting our working group
> deliverable on this topic (now _WAY_ overdue),
> I suggest that obtaining this rich response
> set has shown itself to be too big a bite. I
> propose that it is time to fall back to a single
> REFERDONE reciprocal request, carrying the
> information that is provided in the current
> draft's final response. This would provide a
> baseline version of REFER that would meet the
> requirements the current draft addresses.
> 
> I further propose that when we complete that work,
> we can return to REFER and define an extension that
> would get the richer response set, addressing the
> current lack of definition of that response set
> with something like sip-event profiles.
> 
> RjS
> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 12:28:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17673
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 12:28:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2C48544388; Tue,  9 Jan 2001 11:29:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by lists.bell-labs.com (Postfix) with ESMTP id 7188544383
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 11:28:51 -0500 (EST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 9 Jan 2001 09:27:51 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 09 Jan 2001 09:28:12 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532);
	 Tue, 9 Jan 2001 09:28:12 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0
content-class: urn:content-classes:message
Subject: RE: [SIP] Early media replacement.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9ED@speak.dogfood>
Thread-Topic: [SIP] Early media replacement.
Thread-Index: AcB6XBQPmSnsbE1aRSqiKww3vT1NhwAAszRA
From: "Christian Huitema" <huitema@exchange.microsoft.com>
To: "Rick Dean" <siplist@fdd.com>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
Cc: <sip@lists.bell-labs.com>
X-OriginalArrivalTime: 09 Jan 2001 17:28:12.0163 (UTC) FILETIME=[8A923D30:01C07A61]
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 09:28:11 -0800
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA17673

So far, we have heard three arguments for 183. I would like to take
these
arguments apart, because lumping everything as 'early media' does not
make a lot of sense.

The first argument is that in many cases it is nice to hear the actual
call progress tones and messages, instead of letting the calling UA
synthesize them. This does not by itself mandates the transfer of
SDP information back to the caller; in fact, if it did mandate such
a transfer, we would have a race condition between the beginning
of the progress message and the arrival of the SDP. On the other hand,
if we assume that the 180 code implicitly request the UA to start to
synthesize ringing, then having a different progress code can help.

The second argument is that mixing multiple progress tones is confusing.
But we definitely want to be able to "ring the five telephones in the
house and pick the first one that gets lifted." I think that the
consensus
here is that having a 183 response does not help one bit. If we have
multiple simultaneous ringing, the user is probably better off with
synthesized ringing. So, may be what we need is a rule that says "don't
send multimedia if you received a forked INVITE."

The third argument is that it is in some cases nice to start a two-ways
session without actually starting to bill the call. That one is, IMHO,
bogus. If one wants to provide billing indications, one should do so
by carrying explicit "start of billing" marks. One possibility could
be to answer the call with a 200 OK, maybe with a special header that
says "the call is set temporarily, don't bill yet," and rely on an INFO
message or maybe a subsequent re-invite to actually start billing. In
any case, all procedures that allow for a two-way session without 
billing provide an opening for fraud.

Note that if one wants to actually establish a two-ways session, then
one must in practice make sure that there is only one leg in the call.
This means that this the call was forked, then all branches that were
not selected must be cancelled. This is the semantic of the 200 OK.
This is not the semantic of the 180 message.

In short, there may be a role for a special progress message that 
informs the UA of the call state, but asks the UA to not synthesize 
ringing. There is no obvious need to carry an SDP payload in these
messages; the handling of fork/cancel is much better done if only
the 200 OK can carry an SDP.

-- Christian Huitema

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 12:31:59 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17752
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 12:31:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5918044394; Tue,  9 Jan 2001 11:32:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id C0B1B4438F
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 11:31:19 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f09HV7c15452;
	Tue, 9 Jan 2001 11:31:07 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: Sean Olson <sean.olson@ericsson.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] REFER progress
Message-ID: <20010109113107.A2403@fdd.com>
References: <9BF66EBF6BEFD942915B4D4D45C051F30474A5@DYN-TX-EXCH-001.dynamicsoft.com> <3A5B4740.2090307@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A5B4740.2090307@ericsson.com>; from sean.olson@ericsson.com on Tue, Jan 09, 2001 at 11:15:44AM -0600
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 11:31:07 -0600


On Tue, Jan 09, 2001 at 11:15:44AM -0600, Sean Olson wrote:
> I'm sorry, I don't see the standardization of the
> REFERDONE as being any easier than the standardization
> of a NOTIFY to serve the same purpose.
> 
> To satisfy a need stated by Billy, the
> body of the NOTIFY could simply be the SDP
> from the 200 OK (assuming an INVITE) or empty
> for a BYE. Uses of REFER for other methods would
> need to be specified in extension drafts.
> The Event: token could be "referdone".
> 
> Is there anything else that needs to be specified
> for the use of NOTIFY that I am missing?
> 
> I don't wish to drag this out forever. I think
> the solution is fairly simple and straightforward
> and could be extended in the future.
> 
> Please point out faults with this proposal and
> areas of implementation difficulty.
> /sean
> 

Excellent.  I agree.  No REFERDONE method.
Simply make it a header which is included in 
a method which makes sense.

"refer-status: 200 ok"

This follows the SIP way of everything globbed
into one message.  

--
Rick  :-)
rick_dean@3com.com


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 12:42:20 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18095
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 12:42:20 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 202524433C; Tue,  9 Jan 2001 11:40:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 384D544338
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 11:39:19 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA16245;
	Tue, 9 Jan 2001 12:38:58 -0500 (EST)
Message-ID: <3A5B4CB2.FE570B35@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Rick Dean <siplist@fdd.com>
Cc: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] Early media replacement.
References: <E79883AEA37FD411A58C00508BAC5F4B2B5C30@exchange1.nuera.com> <20010109110903.C27141@fdd.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 12:38:58 -0500
Content-Transfer-Encoding: 7bit

Rick Dean wrote:
> 
> On Mon, Jan 08, 2001 at 11:44:20PM -0800, Fairlie-Cuninghame, Robert wrote:
> >
> > I'm not sure about this. I imagine a common forking cases would a simple
> > "helpdesk" style attendant pool. Where one helpdesk INVITE request is forked
> > to a pool of attendents/extensions and the first to answer is connected. An
> > attendent may have either registered a PSTN/PBX extension to the proxy or
> > they may have forwarded their SIP phone to a PSTN number (mobile phone?) at
> > their local proxy. In this case, the proxy will either not know about the
> > PSTN endpoint or will not be able to do anything about it (ie, must still
> > fork).
> >
> 
> Excellent example.
> 
> Unfortunately, with this design the phone is going to be
> flooded with media from like ten streams.  If the
> media is going to be ignored anyway, then why
> not have the gateways hide it and send 180.
> Should the forking proxy have muted the SDP?
> 
> I do not have a good solution for this example.

This is an indication why tone detection should be done at the gateway
to the extent possible, with only exceptional cases (such as
announcements) be send as real audio. I'm curious what gateways or
switches that interconnect in-band and out-of-band domains do now - do
they generate both messages (e.g., MGCP or IN plus audio) or just
messages or just audio?

In any event, announcements that are not translated to SIP final status
codes would be very confusing. With forking, the caller might hear one
"sorry, the number you have dialed is not in service" because one of the
agents has mis-typed their phone number and the caller will then
disconnect, even though a dozen other agents are ready to answer his
call.

As long as the fundamental information (busy, etc.) is also available as
4/5/6xx responses, the end system would be safe to just play the first
SSRC value. Maybe we need a special RTP designation for high-priority
audio for announcements :-)

(There is the separate issue of the AT&T "smart" 800 redirector that
prompts for input prior to call completion, but that seems less likely
to be an issue in the case presented here.)

Henning
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 12:52:02 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18302
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 12:52:02 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 22BA644338; Tue,  9 Jan 2001 11:52:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id 9B30244337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 11:51:44 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 9 Jan 2001 17:51:33 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id RAA25388; Tue, 9 Jan 2001 17:43:26 GMT
Message-ID: <3A5B4DBD.640AB5A4@ubiquity.net>
From: Neil Deason <ndeason@ubiquity.net>
Organization: Ubiquity Software Corporation Limited
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema <huitema@exchange.microsoft.com>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Michael Thomas <mat@cisco.com>,
        Henning Schulzrinne <hgs@cs.columbia.edu>, sip@lists.bell-labs.com
Subject: Re: [SIP] new record-route text!
References: <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9EC@speak.dogfood>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 17:43:25 +0000
Content-Transfer-Encoding: 7bit

Christian Huitema wrote:
> 
> > Record routing is the ultimate in flexibility. A proxy that
> > doesn't need to
> > be in the call path can get out of the way, and one which
> > needs to be in the
> > call path to serve a useful function, can. It allows people
> > to build sip
> > networks of all different flavors, and have them work with
> > the same UA.
> 
> Jonathan,
> 
> What you are describing are servers that essentially place themselves
> in the middle of a call and want to keep a copy of the call state. In
> my mind, there is no difference between that and a "back-to-back UA"
> implementation. The complexity of such systems derives from their
> desire of being stateful "per call" (as opposed to stateful per
> transaction.) I would argue that the proposed record-route extension
> only makes such servers marginally easier to write; in fact, in may make
> them more complex, since it makes the whole protocol more complex.

It is not just call stateful proxies that want to Record-Route. 
Plain transaction stateful ones do it for some service provision
and distributed architectures. In these cases you certainly don't 
want to be forced to use a b2b UA.

> The discussion has shown that we don't actually need this functionality
> for the basic firewall case. In this case, we need to configure the UA
> with
> the coordinates of the proxy controlling the outgoing calls from the
> firewalled domain; the recording of a route is pretty much implicit. The
> 
> discussion has also outlined that the proxies cannot in any case rely
> entirely on the record-route feature, since UAs may always drop out
> silently; any proxy that keep call state must have some way to clean
> out the state on timeout, or maybe by detecting the loss of the medias.
> 
> I would not object all that much if the specification did not preclude
> bypass of the recorded route, e.g. by issuing a re-invite to the
> contact address through an entirely new path. This would allow the
> conversation to be redirected to a more direct path, or to a path
> that is less dependent of the initial set of proxies. Come to think of
> it, there is no way to prevent UAs to do just that, which means that we
> should not specify the impossible.

As the text stands a UA is not prevented from doing this with
a fresh INVITE just not a reINVITE. Seems like reasonable
flexibility between the UAs and Proxies wants.
The text also says ...
"It is RECOMMENDED that proxies do not automatically record 
route. They should do so only if specifically required."

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 13:36:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19196
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 13:36:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1378844338; Tue,  9 Jan 2001 12:37:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by lists.bell-labs.com (Postfix) with ESMTP id E0C4A44337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 12:36:05 -0500 (EST)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 9 Jan 2001 13:30:06 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBR5K4>; Tue, 9 Jan 2001 13:30:08 -0500
Message-ID: <28560036253BD41191A10000F8BCBD11034BCE34@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: sip@lists.bell-labs.com
Subject: FW: [SIP] REFER open issues
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C07A6A.2E845380"
X-Orig: <taylor@americasm01.nt.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 13:30:03 -0500

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_01C07A6A.2E845380
Content-Type: text/plain;
	charset="iso-8859-1"

Apologies for resending this, but yesterday's transmission still hasn't
shown up on the list.
 
-----Original Message-----
From: Taylor, Tom-PT [NORSE:B901:EXCH] 
Sent: Monday, January 08, 2001 1:10 PM
To: Rohan Mahy; sip@lists.bell-labs.com
Subject: RE: [SIP] REFER open issues


I think part of the problem is to agree on the requirements the method is to
satisfy.  On one side of the debate, we've had pressure to restrict REFER
functionality to call transfer.  On the other is Jonathan's vision of a set
of general primitives.  Thus to add to Rohan's valuable roundup of issues
below, I add a list of alternative functional requirements.  Just to make it
clear that I have my own views on the matter, I list my preferred
alternative first in each case.
 
1) Relation to existing session
(a) REFER can be sent independently of any existing session.
(b) REFER can only be sent on an already-existing call-leg.
(c) ...
 
2) Method invoked by REFER
(a) Any method can be invoked, including BYE.
(b) REFER always asks the receiving party to send an INVITE.
(c) REFER-eligibility varies and must be documented on a per-method basis.
 
3) Notification of results
(a) REFER implicitly subscribes to SIP events at the receiver 
(b) The referror must issue an explicit SUBS to get notification
 
4) Join vs. Replace vs. New
(a) Explicit indication of intent in a header
(b) ...
Note that this is an issue for any receiver of an INVITE, not necessarily
tied to REFER.  As such, it is a matter for another thread, which I will
initiate.

-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Monday, January 08, 2001 11:20 AM
To: sip@lists.bell-labs.com
Subject: Re: [SIP] REFER open issues


 [meeting proposal snipped]
 
 At 10:08 AM 12/15/00 , Rohan Mahy wrote:
>Hi,
>
>I'd like to summarize ALL the open issues that we have with REFER.  In the
>interest of coming to consensus, I'd like to invite interested implementers
>who have comments to meet in person before Minneapolis to close REFER open
>issues.  If folks think this is a good idea, we would certainly post the
>minutes and partial consensus back to the list for comments/changes.  As a
>strawman, I will suggest sometime in the last week of January.  A few
>plausible locations are: Dallas, New York, San Jose...  I volunteer to
>organize this if necessary.
>
>A short summary of the issues are below in no particular order:
>
>1) Retransmission problem:
>Robert Sparks already summarized this problem in his recent post.
>(a) REFER completes early, use explicit SUBSCRIBE for more info
>(b) REFER completes early and implicitly SUBSCRIBEs to more info
>(c) REFER completes after 16 secs and provides URL for SUBSCRIBE
>(d) send new REFER (new CSeq same call ID) after 32 seconds.
>
>2) Cancellation:
>If REFER returns a final response before a long INVITE transaction
>completes, how do you cancel that INVITE?  
>(a) send same REFER with ;method=CANCEL
>(b) send REFERCANCEL method
>
>3) Call-leg matching:
>Should you include call-id's in Refer-to URLs?  If not, what do you use for
>matching (Replaces or similar)?
>(a) match call-ids
>(b) use a Replaces header
>(c) use the mesh-id to setup mesh, then say BYE
>(d) use a new header
>
>4) If we choose Replaces or the like, how do we express that we want to
>*join* 2 legs via REFER?
>(a) Join header
>(b) Associate header
>(c) new method
>(d) something else
>
>5) If Refer-To contains parameters (method, transport), or potentially
>contradictory headers, what do we do with them?
>(a) allow all of them if authorized
>(b) allow a subset of methods/headers
>(c) send an error mesage
>(d) ignore the headers/parameters
>(e) ignore the whole message
>
>6) If we don't allow  ;method=BYE, how do we solve the problem described in
>the Music on 
>Hold flow?
>(a) method=BYE
>(b) ???
>
>7) How do we ask devices to do stuff for us?  [probably defer this issue]
>(a) REFER with parameters/headers
>(b) PHONECTL
>(c) some NEWMETHOD
>(d) Mbus
>(e) other
>
>Any other REFER open issues I missed?
>
>thanks,
>-rohan
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip> 



------_=_NextPart_001_01C07A6A.2E845380
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=701482818-09012001>Apologies for resending this, but yesterday's 
transmission still hasn't shown up on the list.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=701482818-09012001></SPAN></FONT>&nbsp;</DIV>
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
size=2>-----Original Message-----<BR><B>From:</B> Taylor, Tom-PT 
[NORSE:B901:EXCH] <BR><B>Sent:</B> Monday, January 08, 2001 1:10 
PM<BR><B>To:</B> Rohan Mahy; sip@lists.bell-labs.com<BR><B>Subject:</B> RE: 
[SIP] REFER open issues<BR><BR></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>I 
think part of the problem is to agree on the requirements the method is to 
satisfy.&nbsp; On one side of the debate, we've had pressure to restrict REFER 
functionality to call transfer.&nbsp; On the other is Jonathan's vision of a set 
of general primitives.&nbsp; Thus to add to Rohan's valuable roundup of issues 
below, I add a list of alternative functional requirements.&nbsp; Just to make 
it clear that I have my own views on the matter, I list my preferred alternative 
first in each case.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=560280616-08012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>1) 
Relation to existing session</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(a) 
REFER can be sent independently of any existing session.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(b) 
REFER can only be sent on an already-existing call-leg.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(c) 
...</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=560280616-08012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>2) 
Method invoked by REFER</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(a) 
Any method can be invoked, including BYE.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(b) 
</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
class=560280616-08012001>REFER always asks the receiving party to send an 
INVITE.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(c) 
REFER-eligibility varies and must be documented on a per-method 
basis.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=560280616-08012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>3) 
Notification of results</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(a) 
REFER implicitly subscribes to SIP events at the receiver </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=560280616-08012001></SPAN></FONT><FONT color=#0000ff face=Arial 
size=2><SPAN class=560280616-08012001>(b) The referror must issue an explicit 
SUBS to get notification</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=560280616-08012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>4) 
Join vs. Replace vs. New</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(a) 
Explicit indication of intent in a header</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>(b) 
...</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=560280616-08012001>Note 
that this is an issue for any receiver of an INVITE, not necessarily tied to 
REFER.&nbsp; As such, it is a matter for another thread, which I will 
initiate.</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma><FONT 
  size=2>-----Original Message-----<BR><B>From:</B> Rohan Mahy 
  [mailto:rohan@cisco.com]<BR><B>Sent:</B> Monday, January 08, 2001 11:20 
  AM<BR><B>To:</B> sip@lists.bell-labs.com<BR><B>Subject:</B> Re: [SIP] REFER 
  open issues<BR><BR></FONT></DIV>
  <DIV></FONT><SPAN class=560280616-08012001><FONT color=#0000ff face=Arial 
  size=2>&nbsp;<FONT color=#000000 face=Tahoma>[meeting&nbsp;proposal 
  snipped]</FONT></FONT></SPAN></DIV>
  <DIV><SPAN class=560280616-08012001></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=560280616-08012001>&nbsp;</SPAN>At 10:08 AM 12/15/00 , Rohan 
  Mahy wrote:<BR>&gt;Hi,<BR>&gt;<BR>&gt;I'd like to summarize ALL the open 
  issues that we have with REFER.&nbsp; In the<BR>&gt;interest of coming to 
  consensus, I'd like to invite interested implementers<BR>&gt;who have comments 
  to meet in person before Minneapolis to close REFER open<BR>&gt;issues.&nbsp; 
  If folks think this is a good idea, we would certainly post the<BR>&gt;minutes 
  and partial consensus back to the list for comments/changes.&nbsp; As 
  a<BR>&gt;strawman, I will suggest sometime in the last week of January.&nbsp; 
  A few<BR>&gt;plausible locations are: Dallas, New York, San Jose...&nbsp; I 
  volunteer to<BR>&gt;organize this if necessary.<BR>&gt;<BR>&gt;A short summary 
  of the issues are below in no particular order:<BR>&gt;<BR>&gt;1) 
  Retransmission problem:<BR>&gt;Robert Sparks already summarized this problem 
  in his recent post.<BR>&gt;(a) REFER completes early, use explicit SUBSCRIBE 
  for more info<BR>&gt;(b) REFER completes early and implicitly SUBSCRIBEs to 
  more info<BR>&gt;(c) REFER completes after 16 secs and provides URL for 
  SUBSCRIBE<BR>&gt;(d) send new REFER (new CSeq same call ID) after 32 
  seconds.<BR>&gt;<BR>&gt;2) Cancellation:<BR>&gt;If REFER returns a final 
  response before a long INVITE transaction<BR>&gt;completes, how do you cancel 
  that INVITE?&nbsp; <BR>&gt;(a) send same REFER with ;method=CANCEL<BR>&gt;(b) 
  send REFERCANCEL method<BR>&gt;<BR>&gt;3) Call-leg matching:<BR>&gt;Should you 
  include call-id's in Refer-to URLs?&nbsp; If not, what do you use 
  for<BR>&gt;matching (Replaces or similar)?<BR>&gt;(a) match 
  call-ids<BR>&gt;(b) use a Replaces header<BR>&gt;(c) use the mesh-id to setup 
  mesh, then say BYE<BR>&gt;(d) use a new header<BR>&gt;<BR>&gt;4) If we choose 
  Replaces or the like, how do we express that we want to<BR>&gt;*join* 2 legs 
  via REFER?<BR>&gt;(a) Join header<BR>&gt;(b) Associate header<BR>&gt;(c) new 
  method<BR>&gt;(d) something else<BR>&gt;<BR>&gt;5) If Refer-To contains 
  parameters (method, transport), or potentially<BR>&gt;contradictory headers, 
  what do we do with them?<BR>&gt;(a) allow all of them if authorized<BR>&gt;(b) 
  allow a subset of methods/headers<BR>&gt;(c) send an error mesage<BR>&gt;(d) 
  ignore the headers/parameters<BR>&gt;(e) ignore the whole 
  message<BR>&gt;<BR>&gt;6) If we don't allow&nbsp; ;method=BYE, how do we solve 
  the problem described in<BR>&gt;the Music on <BR>&gt;Hold flow?<BR>&gt;(a) 
  method=BYE<BR>&gt;(b) ???<BR>&gt;<BR>&gt;7) How do we ask devices to do stuff 
  for us?&nbsp; [probably defer this issue]<BR>&gt;(a) REFER with 
  parameters/headers<BR>&gt;(b) PHONECTL<BR>&gt;(c) some NEWMETHOD<BR>&gt;(d) 
  Mbus<BR>&gt;(e) other<BR>&gt;<BR>&gt;Any other REFER open issues I 
  missed?<BR>&gt;<BR>&gt;thanks,<BR>&gt;-rohan<BR>&gt;<BR>&gt;<BR>&gt;<BR>&gt;_______________________________________________<BR>&gt;SIP 
  mailing list<BR>&gt;SIP@lists.bell-labs.com<BR>&gt;<A 
  href="http://lists.bell-labs.com/mailman/listinfo/sip" 
  eudora="autourl">http://lists.bell-labs.com/mailman/listinfo/sip</A><BR></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C07A6A.2E845380--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 13:44:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19360
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 13:44:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B484A44366; Tue,  9 Jan 2001 12:45:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id D81DE44338
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 12:44:23 -0500 (EST)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA04330;
	Tue, 9 Jan 2001 10:44:18 -0800 (PST)
Received: from sony-laptop (dhcp-64-102-95-107.cisco.com [64.102.95.107])
	by imop.cisco.com (Mirapoint)
	with SMTP id AAG66305;
	Tue, 9 Jan 2001 10:44:03 -0800 (PST)
Message-Id: <4.1.20010109133250.00cddc20@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
To: Sean Olson <sean.olson@ericsson.com>,
        Robert Sparks <rsparks@dynamicsoft.com>
From: Rohan Mahy <rohan@cisco.com>
Subject: Re: [SIP] REFER progress
Cc: sip@lists.bell-labs.com
In-Reply-To: <3A5B4740.2090307@ericsson.com>
References: <9BF66EBF6BEFD942915B4D4D45C051F30474A5@DYN-TX-EXCH-001.dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 13:49:42 -0500

Hi,

I agree with Sean that an implicit NOTIFY is straightforward, no more
complicated than REFERDONE and solves the timeout problem.  I hope we don't
need a meeting to close this issue.  ;-)

The "other" problem, however, is the one that opened the can of worms.
What primitive(s) do you use to get attended transfer to work?  All of the
proposals (something like 4 of them) work and solve the requirement for an
attended transfer.  Some of these proposals deal more with the  bis draft
(see Tom Taylor's post today).  Everyone seems to want other features as
well, but we need to see at least a "sketch" of the complete features
picture associated with each proposal.  This is why I proposed the one-day
face-to-face meeting.

thanks,
-rohan



At 12:15 PM 1/9/01 , Sean Olson wrote:
>I'm sorry, I don't see the standardization of the
>REFERDONE as being any easier than the standardization
>of a NOTIFY to serve the same purpose.
>
>To satisfy a need stated by Billy, the
>body of the NOTIFY could simply be the SDP
>from the 200 OK (assuming an INVITE) or empty
>for a BYE. Uses of REFER for other methods would
>need to be specified in extension drafts.
>The Event: token could be "referdone".
>
>Is there anything else that needs to be specified
>for the use of NOTIFY that I am missing?
>
>I don't wish to drag this out forever. I think
>the solution is fairly simple and straightforward
>and could be extended in the future.
>
>Please point out faults with this proposal and
>areas of implementation difficulty.
>/sean
>
>Robert Sparks wrote:
>
>> a.s. This got a little long - sorry
>>      It does contain a concrete proposal.
>> ------------
>> I think we are falling into a set of traps
>> with the REFER discussions, endangering an
>> already overdue deliverable.
>> 
>> The worst is specification creep. The group
>> was pretty happy with the functionality of
>> the current draft. When we tripped up on the
>> timeout problem, we saw a host of extra 
>> functionality we could add while working
>> around that problem.
>> 
>> Most of us have gravitated towards a model
>> where REFER is answered with a set of
>> reciprocal responses (essentially NOTIFYs,
>> possibly of a different name, with or without
>> an explicit subscribe). What we _haven't_
>> spent much time on is the profile of those
>> responses. How many can there be? What do
>> they contain?
>> 
>> I really anticipate the answers to those last
>> questions will vary widely depending on the
>> application using REFER. We want to be able
>> to do other things than transfer (this is 
>> why the method got renamed from TRANSFER).
>> A rich response set for a REFER that triggers
>> a SUBSCRIBE is likely to be entirely different
>> in character from one that triggers an INVITE.
>> 
>> 
>> PROPOSAL
>> In interests of meeting our working group
>> deliverable on this topic (now _WAY_ overdue),
>> I suggest that obtaining this rich response
>> set has shown itself to be too big a bite. I
>> propose that it is time to fall back to a single
>> REFERDONE reciprocal request, carrying the
>> information that is provided in the current
>> draft's final response. This would provide a
>> baseline version of REFER that would meet the
>> requirements the current draft addresses.
>> 
>> I further propose that when we complete that work,
>> we can return to REFER and define an extension that
>> would get the richer response set, addressing the
>> current lack of definition of that response set
>> with something like sip-event profiles.
>> 
>> RjS
>> 
>> 
>> 
>> _______________________________________________
>> SIP mailing list
>> SIP@lists.bell-labs.com
>> http://lists.bell-labs.com/mailman/listinfo/sip
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 14:15:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19869
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 14:15:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 669EB44338; Tue,  9 Jan 2001 13:16:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by lists.bell-labs.com (Postfix) with ESMTP id D440744337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 13:15:01 -0500 (EST)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA07111;
	Tue, 9 Jan 2001 11:14:52 -0800 (PST)
Received: from sony-laptop (dhcp-64-102-95-107.cisco.com [64.102.95.107])
	by imop.cisco.com (Mirapoint)
	with SMTP id AAG66848;
	Tue, 9 Jan 2001 11:14:41 -0800 (PST)
Message-Id: <4.1.20010109135149.00ba4f00@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
To: "Rosen, Brian" <Brian.Rosen@marconi.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        sip@lists.bell-labs.com
From: Rohan Mahy <rohan@cisco.com>
Subject: RE: [SIP] REFER open issues
In-Reply-To: <4FBEA8857476D311A03300204840E1CF01A6EC9B@whq-msgusr-02.pit
 .comms.marconi.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_15082097==_.ALT"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 14:20:20 -0500

--=====================_15082097==_.ALT
Content-Type: text/plain; charset="us-ascii"

Brian, Jonathan,

I think we need to focus on one topic at a time.  I'd be happy to spend a day
working on "Call Control" as a chartered topic area, but this topic needs a
whole day.  

By my count, of the nearly 100 email messages exchanged on topics related to
REFER, only 20 people were involved, most sent only a single reply for
clarification or consensus with a previous message, only 8 people sent more
than 3 messages on the topic:
(Robert Sparks, Venkatesh, Billy Biggs, Rick Dean, Henning, Jonathan R, Tom
Taylor, Sean Olson, and me)

I picked this item because it is a charter item with active list discussion not
reaching consensus, but a relatively small number needed for quorum.

Sure, some of the people will overlap, but you'd need a mostly different group
to discuss proxy issuues, or security, or telephony intergration issues.

thanks,
-rohan


At 08:00 AM 1/9/01 , Rosen, Brian wrote: 
>
> Depends on the players.
>  
> If the same folks need to solve multiple problems, then Jonathan is right. 
> If the cast
> of characters changes, than single purpose meetings work.  I suspect the same
> folks
> need to be at most if not all these meetings, and thus we need to have a
> (small)
> set of problems to solve.
>  
> I don't want to spoil Rohan's initiative however.  So, let's 
>         Respond to his request
>         Make a (small) list of other topics to cover
>  
> Brian
>>
>> -----Original Message----- 
>> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] 
>> Sent: Tuesday, January 09, 2001 2:35 AM 
>> To: 'Rohan Mahy'; sip@lists.bell-labs.com 
>> Subject: RE: [SIP] REFER open issues
>>
>> I don't want to have an interim meeting JUST on REFER. There are lots of
>> other open issues. We should seek to accomplish as much as possible in one
>> meeting, rather than having meetings for each issue.  
>>   
>> -Jonathan R. 
>>  
>>
>> Jonathan D. Rosenberg                       72 Eagle Rock Ave. 
>> Chief Scientist                             First Floor 
>> dynamicsoft                                 East Hanover, NJ 07936 
>> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050 
>>
>> <http://www.cs.columbia.edu/~jdrosen>http://www.cs.columbia.edu/~jdrosen
>>   PHONE: (973) 952-5000 
>> <http://www.dynamicsoft.com/>http://www.dynamicsoft.com 
>>    
>> -----Original Message----- 
>> From: Rohan Mahy [mailto:rohan@cisco.com] 
>> Sent: Monday, January 08, 2001 11:20 AM 
>> To: sip@lists.bell-labs.com 
>> Subject: Re: [SIP] REFER open issues
>>
>> Hi,
>>
>> I've heard some mixed interest at the IETF, and no objections to an interim
>> meeting to build some consensus around REFER open issues.  If you are
>> intersted in attending a meeting **and have posted to the list on one of
>> these REFER-related topics**, please indicate your availability and ability
>> to travel to some sample US destinations the last week of January/first week
>> of February by filling in the grid below.  an [x] means you are available, a
>> [?] is a maybe.
>>
>> Of course all the meeting minutes, proposals, etc will get posted back to
>> this list. 
>> Again, please do not spam the whole list with your availability.  I'll post
>> a summary.
>>
>>         Please use a fixed-width font such as Courier.
>>
>>         Available    San Jose   Dallas   New York  RaleighNC  Other
>>
>> Jan 29    [ ]           [ ]      [ ]        [ ]       [ ]      [ ] 
>>     30    [ ]           [ ]      [ ]        [ ]       [ ]      [ ] 
>>     31    [ ]           [ ]      [ ]        [ ]       [ ]      [ ] 
>> Feb  1    [ ]           [ ]      [ ]        [ ]       [ ]      [ ] 
>>      2    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
>>
>>      5    [ ]           [ ]      [ ]        [ ]       [ ]      [ ] 
>>      6    [ ]           [ ]      [ ]        [ ]       [ ]      [ ] 
>>      7    [ ]           [ ]      [ ]        [ ]       [ ]      [ ] 
>>      8    [ ]           [ ]      [ ]        [ ]       [ ]      [ ] 
>>      9    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]
>>
>>
>>
>> thanks, 
>> -rohan
>>
>>
>>
>> At 10:08 AM 12/15/00 , Rohan Mahy wrote: 
>> >Hi, 
>> > 
>> >I'd like to summarize ALL the open issues that we have with REFER.  In the 
>> >interest of coming to consensus, I'd like to invite interested implementers
>> >who have comments to meet in person before Minneapolis to close REFER open 
>> >issues.  If folks think this is a good idea, we would certainly post the 
>> >minutes and partial consensus back to the list for comments/changes.  As a 
>> >strawman, I will suggest sometime in the last week of January.  A few 
>> >plausible locations are: Dallas, New York, San Jose...  I volunteer to 
>> >organize this if necessary. 
>> > 
>> >A short summary of the issues are below in no particular order: 
>> > 
>> >1) Retransmission problem: 
>> >Robert Sparks already summarized this problem in his recent post. 
>> >(a) REFER completes early, use explicit SUBSCRIBE for more info 
>> >(b) REFER completes early and implicitly SUBSCRIBEs to more info 
>> >(c) REFER completes after 16 secs and provides URL for SUBSCRIBE 
>> >(d) send new REFER (new CSeq same call ID) after 32 seconds. 
>> > 
>> >2) Cancellation: 
>> >If REFER returns a final response before a long INVITE transaction 
>> >completes, how do you cancel that INVITE?  
>> >(a) send same REFER with ;method=CANCEL 
>> >(b) send REFERCANCEL method 
>> > 
>> >3) Call-leg matching: 
>> >Should you include call-id's in Refer-to URLs?  If not, what do you use for
>> >matching (Replaces or similar)? 
>> >(a) match call-ids 
>> >(b) use a Replaces header 
>> >(c) use the mesh-id to setup mesh, then say BYE 
>> >(d) use a new header 
>> > 
>> >4) If we choose Replaces or the like, how do we express that we want to 
>> >*join* 2 legs via REFER? 
>> >(a) Join header 
>> >(b) Associate header 
>> >(c) new method 
>> >(d) something else 
>> > 
>> >5) If Refer-To contains parameters (method, transport), or potentially 
>> >contradictory headers, what do we do with them? 
>> >(a) allow all of them if authorized 
>> >(b) allow a subset of methods/headers 
>> >(c) send an error mesage 
>> >(d) ignore the headers/parameters 
>> >(e) ignore the whole message 
>> > 
>> >6) If we don't allow  ;method=BYE, how do we solve the problem described in
>> >the Music on 
>> >Hold flow? 
>> >(a) method=BYE 
>> >(b) ??? 
>> > 
>> >7) How do we ask devices to do stuff for us?  [probably defer this issue] 
>> >(a) REFER with parameters/headers 
>> >(b) PHONECTL 
>> >(c) some NEWMETHOD 
>> >(d) Mbus 
>> >(e) other 
>> > 
>> >Any other REFER open issues I missed? 
>> > 
>> >thanks, 
>> >-rohan 
>> > 
>> > 
>> > 
>> >_______________________________________________ 
>> >SIP mailing list 
>> >SIP@lists.bell-labs.com 
>> >http://lists.bell-labs.com/mailman/listinfo/sip
>>
>
>

--=====================_15082097==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Brian, Jonathan,<br>
<br>
I think we need to focus on one topic at a time.&nbsp; I'd be happy to
spend a day working on &quot;Call Control&quot; as a chartered topic
area, but this topic needs a whole day.&nbsp; <br>
<br>
By my count, of the nearly 100 email messages exchanged on topics related
to REFER, only 20 people were involved, most sent only a single reply for
clarification or consensus with a previous message, only 8 people sent
more than 3 messages on the topic:<br>
(Robert Sparks, Venkatesh, Billy Biggs, Rick Dean, Henning, Jonathan R,
Tom Taylor, Sean Olson, and me)<br>
<br>
I picked this item because it is a charter item with active list
discussion not reaching consensus, but a relatively small number needed
for quorum.<br>
<br>
Sure, some of the people will overlap, but you'd need a mostly different
group to discuss proxy issuues, or security, or telephony intergration
issues.<br>
<br>
thanks,<br>
-rohan<br>
<br>
<br>
At 08:00 AM 1/9/01 , Rosen, Brian wrote: <br>
<font face="arial" color="#0000FF"><blockquote type=cite cite>Depends on
the players.</font><br>
&nbsp;<br>
<font face="arial" color="#0000FF">If the same folks need to solve
multiple problems, then Jonathan is right.&nbsp; If the cast</font><br>
of characters changes, than single purpose meetings work.&nbsp; I suspect
the same folks<br>
need to be at most if not all these meetings, and thus we need to have a
(small)<br>
set of problems to solve.<br>
&nbsp;<br>
<font face="arial" color="#0000FF">I don't want to spoil Rohan's
initiative however.&nbsp; So, let's </font><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<font face="arial" color="#0000FF">Respond to his request</font><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<font face="arial" color="#0000FF">Make a (small) list of other topics to
cover</font><br>
&nbsp;<br>
<font face="arial" color="#0000FF">Brian</font><blockquote><font face="tahoma" size=2>
<dl>
<dd>-----Original Message-----
<dd>From:</b> Jonathan Rosenberg
[<a href="mailto:jdrosen@dynamicsoft.com" eudora="autourl">mailto:jdrosen@dynamicsoft.com</a>]
<dd>Sent:</b> Tuesday, January 09, 2001 2:35 AM
<dd>To:</b> 'Rohan Mahy'; sip@lists.bell-labs.com
<dd>Subject:</b> RE: [SIP] REFER open issues<br>
<br>
</font><font face="Courier New, Courier" size=2 color="#0000FF">
<dd>I don't want to have an interim meeting JUST on REFER. There are lots
of other open issues. We should seek to accomplish as much as possible in
one meeting, rather than having meetings for each issue. </font>
<dd>&nbsp;<font face="Courier New, Courier" size=2 color="#0000FF">
<dd>-Jonathan R.</font>
<dd>&nbsp;<br>
<br>
<font size=2>
<dd>Jonathan D.
Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
72 Eagle Rock Ave.
<dd>Chief
Scientist&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;
First Floor
<dd>dynamicsoft&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;
East Hanover, NJ 07936
<dd>jdrosen@dynamicsoft.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
FAX:&nbsp;&nbsp; (973) 952-5050
<dd><a href="http://www.cs.columbia.edu/~jdrosen">http://www.cs.columbia.edu/~jdrosen</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PHONE: (973) 952-5000
<dd><a href="http://www.dynamicsoft.com/">http://www.dynamicsoft.com</a>
<dd>&nbsp;</font> <font face="tahoma" size=2>
<dd>-----Original Message-----
<dd>From:</b> Rohan Mahy
[<a href="mailto:rohan@cisco.com" eudora="autourl">mailto:rohan@cisco.com</a>]
<dd>Sent:</b> Monday, January 08, 2001 11:20 AM
<dd>To:</b> sip@lists.bell-labs.com
<dd>Subject:</b> Re: [SIP] REFER open issues<br>
<br>
</font>
<dd>Hi,<br>
<br>

<dd>I've heard some mixed interest at the IETF, and no objections to an
interim meeting to build some consensus around REFER open issues.&nbsp;
If you are intersted in attending a meeting **and have posted to the list
on one of these REFER-related topics**, please indicate your availability
and ability to travel to some sample US destinations the last week of
January/first week of February by filling in the grid below.&nbsp; an [x]
means you are available, a [?] is a maybe.<br>
<br>

<dd>Of course all the meeting minutes, proposals, etc will get posted
back to this list.
<dd>Again, please do not spam the whole list with your
availability.&nbsp; I'll post a summary.<br>
<br>
<font face="Courier, Courier">
<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Please use a fixed-width
font such as Courier.<br>
<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Available&nbsp;&nbsp;&nbsp; San Jose&nbsp;&nbsp; Dallas&nbsp;&nbsp; New
York&nbsp; RaleighNC&nbsp; Other<br>
<br>

<dd>Jan 29&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; [
]
<dd>&nbsp;&nbsp;&nbsp; 30&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; [
]
<dd>&nbsp;&nbsp;&nbsp; 31&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; [
]
<dd>Feb&nbsp; 1&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; [
]
<dd>&nbsp;&nbsp;&nbsp;&nbsp; 2&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>
<br>

<dd>&nbsp;&nbsp;&nbsp;&nbsp; 5&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; [
]
<dd>&nbsp;&nbsp;&nbsp;&nbsp; 6&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; [
]
<dd>&nbsp;&nbsp;&nbsp;&nbsp; 7&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; [
]
<dd>&nbsp;&nbsp;&nbsp;&nbsp; 8&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; [
]
<dd>&nbsp;&nbsp;&nbsp;&nbsp; 9&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>
<br>
<br>
<br>
</font>
<dd>thanks,
<dd>-rohan<br>
<br>
<br>
<br>

<dd>At 10:08 AM 12/15/00 , Rohan Mahy wrote:
<dd>&gt;Hi,
<dd>&gt;
<dd>&gt;I'd like to summarize ALL the open issues that we have with
REFER.&nbsp; In the
<dd>&gt;interest of coming to consensus, I'd like to invite interested
implementers
<dd>&gt;who have comments to meet in person before Minneapolis to close
REFER open
<dd>&gt;issues.&nbsp; If folks think this is a good idea, we would
certainly post the
<dd>&gt;minutes and partial consensus back to the list for
comments/changes.&nbsp; As a
<dd>&gt;strawman, I will suggest sometime in the last week of
January.&nbsp; A few
<dd>&gt;plausible locations are: Dallas, New York, San Jose...&nbsp; I
volunteer to
<dd>&gt;organize this if necessary.
<dd>&gt;
<dd>&gt;A short summary of the issues are below in no particular order:
<dd>&gt;
<dd>&gt;1) Retransmission problem:
<dd>&gt;Robert Sparks already summarized this problem in his recent
post.
<dd>&gt;(a) REFER completes early, use explicit SUBSCRIBE for more info
<dd>&gt;(b) REFER completes early and implicitly SUBSCRIBEs to more 
info
<dd>&gt;(c) REFER completes after 16 secs and provides URL for 
SUBSCRIBE
<dd>&gt;(d) send new REFER (new CSeq same call ID) after 32 seconds.
<dd>&gt;
<dd>&gt;2) Cancellation:
<dd>&gt;If REFER returns a final response before a long INVITE
transaction
<dd>&gt;completes, how do you cancel that INVITE?&nbsp; 
<dd>&gt;(a) send same REFER with ;method=CANCEL
<dd>&gt;(b) send REFERCANCEL method
<dd>&gt;
<dd>&gt;3) Call-leg matching:
<dd>&gt;Should you include call-id's in Refer-to URLs?&nbsp; If not, what
do you use for
<dd>&gt;matching (Replaces or similar)?
<dd>&gt;(a) match call-ids
<dd>&gt;(b) use a Replaces header
<dd>&gt;(c) use the mesh-id to setup mesh, then say BYE
<dd>&gt;(d) use a new header
<dd>&gt;
<dd>&gt;4) If we choose Replaces or the like, how do we express that we
want to
<dd>&gt;*join* 2 legs via REFER?
<dd>&gt;(a) Join header
<dd>&gt;(b) Associate header
<dd>&gt;(c) new method
<dd>&gt;(d) something else
<dd>&gt;
<dd>&gt;5) If Refer-To contains parameters (method, transport), or
potentially
<dd>&gt;contradictory headers, what do we do with them?
<dd>&gt;(a) allow all of them if authorized
<dd>&gt;(b) allow a subset of methods/headers
<dd>&gt;(c) send an error mesage
<dd>&gt;(d) ignore the headers/parameters
<dd>&gt;(e) ignore the whole message
<dd>&gt;
<dd>&gt;6) If we don't allow&nbsp; ;method=BYE, how do we solve the
problem described in
<dd>&gt;the Music on 
<dd>&gt;Hold flow?
<dd>&gt;(a) method=BYE
<dd>&gt;(b) ???
<dd>&gt;
<dd>&gt;7) How do we ask devices to do stuff for us?&nbsp; [probably
defer this issue]
<dd>&gt;(a) REFER with parameters/headers
<dd>&gt;(b) PHONECTL
<dd>&gt;(c) some NEWMETHOD
<dd>&gt;(d) Mbus
<dd>&gt;(e) other
<dd>&gt;
<dd>&gt;Any other REFER open issues I missed?
<dd>&gt;
<dd>&gt;thanks,
<dd>&gt;-rohan
<dd>&gt;
<dd>&gt;
<dd>&gt;
<dd>&gt;_______________________________________________
<dd>&gt;SIP mailing list
<dd>&gt;SIP@lists.bell-labs.com
<dd>&gt;<a href="http://lists.bell-labs.com/mailman/listinfo/sip" eudora="autourl">http://lists.bell-labs.com/mailman/listinfo/sip</a><br>
<br>

</dl></blockquote><br>
</html>

--=====================_15082097==_.ALT--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 14:27:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20035
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 14:27:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F0B9044399; Tue,  9 Jan 2001 13:28:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id BE2E944338
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 13:27:05 -0500 (EST)
Received: from CINQUECENTO ([63.110.3.212])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id OAA23176;
	Tue, 9 Jan 2001 14:29:32 -0500 (EST)
From: "Robert Sparks" <rsparks@dynamicsoft.com>
To: "'Rohan Mahy'" <rohan@cisco.com>, "Sean Olson" <sean.olson@ericsson.com>,
        "Robert Sparks" <rsparks@dynamicsoft.com>
Cc: <sip@lists.bell-labs.com>
Subject: RE: [SIP] REFER progress
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30474AB@DYN-TX-EXCH-001.dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <4.1.20010109133250.00cddc20@imop.cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 13:23:34 -0600
Content-Transfer-Encoding: 7bit

As far as I can thell, You and Sean are assuming you get
exactly one NOTIFY then. 

At that point we're just quibbling on the method name.

Or do you disagree? If you are assuming more than one
NOTIFY, then I think you missed my point.

RjS



> -----Original Message-----
> From: Rohan Mahy [mailto:rohan@cisco.com]
> Sent: Tuesday, January 09, 2001 12:50 PM
> To: Sean Olson; Robert Sparks
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] REFER progress
> 
> 
> Hi,
> 
> I agree with Sean that an implicit NOTIFY is straightforward, no more
> complicated than REFERDONE and solves the timeout problem.  I 
> hope we don't
> need a meeting to close this issue.  ;-)
> 
> The "other" problem, however, is the one that opened the can of worms.
> What primitive(s) do you use to get attended transfer to 
> work?  All of the
> proposals (something like 4 of them) work and solve the 
> requirement for an
> attended transfer.  Some of these proposals deal more with 
> the  bis draft
> (see Tom Taylor's post today).  Everyone seems to want other 
> features as
> well, but we need to see at least a "sketch" of the complete features
> picture associated with each proposal.  This is why I 
> proposed the one-day
> face-to-face meeting.
> 
> thanks,
> -rohan
> 
> 
> 
> At 12:15 PM 1/9/01 , Sean Olson wrote:
> >I'm sorry, I don't see the standardization of the
> >REFERDONE as being any easier than the standardization
> >of a NOTIFY to serve the same purpose.
> >
> >To satisfy a need stated by Billy, the
> >body of the NOTIFY could simply be the SDP
> >from the 200 OK (assuming an INVITE) or empty
> >for a BYE. Uses of REFER for other methods would
> >need to be specified in extension drafts.
> >The Event: token could be "referdone".
> >
> >Is there anything else that needs to be specified
> >for the use of NOTIFY that I am missing?
> >
> >I don't wish to drag this out forever. I think
> >the solution is fairly simple and straightforward
> >and could be extended in the future.
> >
> >Please point out faults with this proposal and
> >areas of implementation difficulty.
> >/sean
> >
> >Robert Sparks wrote:
> >
> >> a.s. This got a little long - sorry
> >>      It does contain a concrete proposal.
> >> ------------
> >> I think we are falling into a set of traps
> >> with the REFER discussions, endangering an
> >> already overdue deliverable.
> >> 
> >> The worst is specification creep. The group
> >> was pretty happy with the functionality of
> >> the current draft. When we tripped up on the
> >> timeout problem, we saw a host of extra 
> >> functionality we could add while working
> >> around that problem.
> >> 
> >> Most of us have gravitated towards a model
> >> where REFER is answered with a set of
> >> reciprocal responses (essentially NOTIFYs,
> >> possibly of a different name, with or without
> >> an explicit subscribe). What we _haven't_
> >> spent much time on is the profile of those
> >> responses. How many can there be? What do
> >> they contain?
> >> 
> >> I really anticipate the answers to those last
> >> questions will vary widely depending on the
> >> application using REFER. We want to be able
> >> to do other things than transfer (this is 
> >> why the method got renamed from TRANSFER).
> >> A rich response set for a REFER that triggers
> >> a SUBSCRIBE is likely to be entirely different
> >> in character from one that triggers an INVITE.
> >> 
> >> 
> >> PROPOSAL
> >> In interests of meeting our working group
> >> deliverable on this topic (now _WAY_ overdue),
> >> I suggest that obtaining this rich response
> >> set has shown itself to be too big a bite. I
> >> propose that it is time to fall back to a single
> >> REFERDONE reciprocal request, carrying the
> >> information that is provided in the current
> >> draft's final response. This would provide a
> >> baseline version of REFER that would meet the
> >> requirements the current draft addresses.
> >> 
> >> I further propose that when we complete that work,
> >> we can return to REFER and define an extension that
> >> would get the richer response set, addressing the
> >> current lack of definition of that response set
> >> with something like sip-event profiles.
> >> 
> >> RjS
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> SIP mailing list
> >> SIP@lists.bell-labs.com
> >> http://lists.bell-labs.com/mailman/listinfo/sip
> >
> >
> >_______________________________________________
> >SIP mailing list
> >SIP@lists.bell-labs.com
> >http://lists.bell-labs.com/mailman/listinfo/sip
> 


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 14:31:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20165
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 14:31:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E5DD6443A9; Tue,  9 Jan 2001 13:32:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by lists.bell-labs.com (Postfix) with ESMTP id 71A754438E
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 13:31:02 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14402;
	Tue, 9 Jan 2001 14:30:48 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA18181;
	Tue, 9 Jan 2001 14:30:50 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <CRQSLRKS>; Tue, 9 Jan 2001 14:30:49 -0500
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6ECB7@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Rohan Mahy'" <rohan@cisco.com>,
        "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        sip@lists.bell-labs.com
Subject: RE: [SIP] REFER open issues
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C07A72.AAF817A0"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 14:30:47 -0500

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_01C07A72.AAF817A0
Content-Type: text/plain;
	charset="iso-8859-1"

The problem here is travel.  If it's a whole day, then most people will suck
up 2 days.
If we have, say 3 or 4 topics, and we can organize well, we might get that
done in 2 long days, plus travel.
 
Brian

-----Original Message-----
From: Rohan Mahy [mailto:rohan@cisco.com]
Sent: Tuesday, January 09, 2001 2:20 PM
To: Rosen, Brian; 'Jonathan Rosenberg'; sip@lists.bell-labs.com
Subject: RE: [SIP] REFER open issues


Brian, Jonathan,

I think we need to focus on one topic at a time.  I'd be happy to spend a
day working on "Call Control" as a chartered topic area, but this topic
needs a whole day.  

By my count, of the nearly 100 email messages exchanged on topics related to
REFER, only 20 people were involved, most sent only a single reply for
clarification or consensus with a previous message, only 8 people sent more
than 3 messages on the topic:
(Robert Sparks, Venkatesh, Billy Biggs, Rick Dean, Henning, Jonathan R, Tom
Taylor, Sean Olson, and me)

I picked this item because it is a charter item with active list discussion
not reaching consensus, but a relatively small number needed for quorum.

Sure, some of the people will overlap, but you'd need a mostly different
group to discuss proxy issuues, or security, or telephony intergration
issues.

thanks,
-rohan


At 08:00 AM 1/9/01 , Rosen, Brian wrote: 


Depends on the players.
 
If the same folks need to solve multiple problems, then Jonathan is right.
If the cast
of characters changes, than single purpose meetings work.  I suspect the
same folks
need to be at most if not all these meetings, and thus we need to have a
(small)
set of problems to solve.
 
I don't want to spoil Rohan's initiative however.  So, let's 
        Respond to his request
        Make a (small) list of other topics to cover
 
Brian 



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

From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com
<mailto:jdrosen@dynamicsoft.com> ] 

Sent: Tuesday, January 09, 2001 2:35 AM 

To: 'Rohan Mahy'; sip@lists.bell-labs.com 

Subject: RE: [SIP] REFER open issues



I don't want to have an interim meeting JUST on REFER. There are lots of
other open issues. We should seek to accomplish as much as possible in one
meeting, rather than having meetings for each issue. 



-Jonathan R. 



  

Jonathan D. Rosenberg                       72 Eagle Rock Ave. 

Chief Scientist                             First Floor 

dynamicsoft                                 East Hanover, NJ 07936 

jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050 

http://www.cs.columbia.edu/~jdrosen <http://www.cs.columbia.edu/~jdrosen>
PHONE: (973) 952-5000 

http://www.dynamicsoft.com <http://www.dynamicsoft.com/>  

  

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

From: Rohan Mahy [ mailto:rohan@cisco.com <mailto:rohan@cisco.com> ] 

Sent: Monday, January 08, 2001 11:20 AM 

To: sip@lists.bell-labs.com 

Subject: Re: [SIP] REFER open issues



Hi,



I've heard some mixed interest at the IETF, and no objections to an interim
meeting to build some consensus around REFER open issues.  If you are
intersted in attending a meeting **and have posted to the list on one of
these REFER-related topics**, please indicate your availability and ability
to travel to some sample US destinations the last week of January/first week
of February by filling in the grid below.  an [x] means you are available, a
[?] is a maybe.



Of course all the meeting minutes, proposals, etc will get posted back to
this list. 

Again, please do not spam the whole list with your availability.  I'll post
a summary.



        Please use a fixed-width font such as Courier.



        Available    San Jose   Dallas   New York  RaleighNC  Other



Jan 29    [ ]           [ ]      [ ]        [ ]       [ ]      [ ] 

    30    [ ]           [ ]      [ ]        [ ]       [ ]      [ ] 

    31    [ ]           [ ]      [ ]        [ ]       [ ]      [ ] 

Feb  1    [ ]           [ ]      [ ]        [ ]       [ ]      [ ] 

     2    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]



     5    [ ]           [ ]      [ ]        [ ]       [ ]      [ ] 

     6    [ ]           [ ]      [ ]        [ ]       [ ]      [ ] 

     7    [ ]           [ ]      [ ]        [ ]       [ ]      [ ] 

     8    [ ]           [ ]      [ ]        [ ]       [ ]      [ ] 

     9    [ ]           [ ]      [ ]        [ ]       [ ]      [ ]





thanks, 

-rohan





At 10:08 AM 12/15/00 , Rohan Mahy wrote: 

>Hi, 

> 

>I'd like to summarize ALL the open issues that we have with REFER.  In the 

>interest of coming to consensus, I'd like to invite interested implementers


>who have comments to meet in person before Minneapolis to close REFER open 

>issues.  If folks think this is a good idea, we would certainly post the 

>minutes and partial consensus back to the list for comments/changes.  As a 

>strawman, I will suggest sometime in the last week of January.  A few 

>plausible locations are: Dallas, New York, San Jose...  I volunteer to 

>organize this if necessary. 

> 

>A short summary of the issues are below in no particular order: 

> 

>1) Retransmission problem: 

>Robert Sparks already summarized this problem in his recent post. 

>(a) REFER completes early, use explicit SUBSCRIBE for more info 

>(b) REFER completes early and implicitly SUBSCRIBEs to more info 

>(c) REFER completes after 16 secs and provides URL for SUBSCRIBE 

>(d) send new REFER (new CSeq same call ID) after 32 seconds. 

> 

>2) Cancellation: 

>If REFER returns a final response before a long INVITE transaction 

>completes, how do you cancel that INVITE?  

>(a) send same REFER with ;method=CANCEL 

>(b) send REFERCANCEL method 

> 

>3) Call-leg matching: 

>Should you include call-id's in Refer-to URLs?  If not, what do you use for


>matching (Replaces or similar)? 

>(a) match call-ids 

>(b) use a Replaces header 

>(c) use the mesh-id to setup mesh, then say BYE 

>(d) use a new header 

> 

>4) If we choose Replaces or the like, how do we express that we want to 

>*join* 2 legs via REFER? 

>(a) Join header 

>(b) Associate header 

>(c) new method 

>(d) something else 

> 

>5) If Refer-To contains parameters (method, transport), or potentially 

>contradictory headers, what do we do with them? 

>(a) allow all of them if authorized 

>(b) allow a subset of methods/headers 

>(c) send an error mesage 

>(d) ignore the headers/parameters 

>(e) ignore the whole message 

> 

>6) If we don't allow  ;method=BYE, how do we solve the problem described in


>the Music on 

>Hold flow? 

>(a) method=BYE 

>(b) ??? 

> 

>7) How do we ask devices to do stuff for us?  [probably defer this issue] 

>(a) REFER with parameters/headers 

>(b) PHONECTL 

>(c) some NEWMETHOD 

>(d) Mbus 

>(e) other 

> 

>Any other REFER open issues I missed? 

> 

>thanks, 

>-rohan 

> 

> 

> 

>_______________________________________________ 

>SIP mailing list 

>SIP@lists.bell-labs.com 

> http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip> 





------_=_NextPart_001_01C07A72.AAF817A0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.50.4207.2601" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=712252919-09012001><FONT face=Arial color=#0000ff>The problem 
here is travel.&nbsp; If it's a whole day, then most people will suck up 2 
days.</FONT></SPAN></DIV>
<DIV><SPAN class=712252919-09012001><FONT face=Arial color=#0000ff>If we have, 
say 3 or 4 topics, and we can organize well, we might get that done in 2 long 
days, plus travel.</FONT></SPAN></DIV>
<DIV><SPAN class=712252919-09012001><FONT face=Arial 
color=#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=712252919-09012001><FONT face=Arial 
color=#0000ff>Brian</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Rohan Mahy 
  [mailto:rohan@cisco.com]<BR><B>Sent:</B> Tuesday, January 09, 2001 2:20 
  PM<BR><B>To:</B> Rosen, Brian; 'Jonathan Rosenberg'; 
  sip@lists.bell-labs.com<BR><B>Subject:</B> RE: [SIP] REFER open 
  issues<BR><BR></FONT></DIV>Brian, Jonathan,<BR><BR>I think we need to focus on 
  one topic at a time.&nbsp; I'd be happy to spend a day working on "Call 
  Control" as a chartered topic area, but this topic needs a whole day.&nbsp; 
  <BR><BR>By my count, of the nearly 100 email messages exchanged on topics 
  related to REFER, only 20 people were involved, most sent only a single reply 
  for clarification or consensus with a previous message, only 8 people sent 
  more than 3 messages on the topic:<BR>(Robert Sparks, Venkatesh, Billy Biggs, 
  Rick Dean, Henning, Jonathan R, Tom Taylor, Sean Olson, and me)<BR><BR>I 
  picked this item because it is a charter item with active list discussion not 
  reaching consensus, but a relatively small number needed for 
  quorum.<BR><BR>Sure, some of the people will overlap, but you'd need a mostly 
  different group to discuss proxy issuues, or security, or telephony 
  intergration issues.<BR><BR>thanks,<BR>-rohan<BR><BR><BR>At 08:00 AM 1/9/01 , 
  Rosen, Brian wrote: <BR><FONT face=arial color=#0000ff>
  <BLOCKQUOTE cite type="cite">Depends on the 
    players.</FONT><BR>&nbsp;<BR><FONT face=arial color=#0000ff>If the same 
    folks need to solve multiple problems, then Jonathan is right.&nbsp; If the 
    cast</FONT><BR>of characters changes, than single purpose meetings 
    work.&nbsp; I suspect the same folks<BR>need to be at most if not all these 
    meetings, and thus we need to have a (small)<BR>set of problems to 
    solve.<BR>&nbsp;<BR><FONT face=arial color=#0000ff>I don't want to spoil 
    Rohan's initiative however.&nbsp; So, let's 
    </FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=arial 
    color=#0000ff>Respond to his 
    request</FONT><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT 
    face=arial color=#0000ff>Make a (small) list of other topics to 
    cover</FONT><BR>&nbsp;<BR><FONT face=arial color=#0000ff>Brian</FONT>
    <BLOCKQUOTE><FONT face=tahoma size=2>
      <DL>
        <DD>-----Original Message----- 
        <DD>From:</B> Jonathan Rosenberg [<A 
        href="mailto:jdrosen@dynamicsoft.com" 
        eudora="autourl">mailto:jdrosen@dynamicsoft.com</A>] 
        <DD>Sent:</B> Tuesday, January 09, 2001 2:35 AM 
        <DD>To:</B> 'Rohan Mahy'; sip@lists.bell-labs.com 
        <DD>Subject:</B> RE: [SIP] REFER open issues<BR><BR></FONT><FONT 
        face="Courier New, Courier" color=#0000ff size=2>
        <DD>I don't want to have an interim meeting JUST on REFER. There are 
        lots of other open issues. We should seek to accomplish as much as 
        possible in one meeting, rather than having meetings for each issue. 
        </FONT>
        <DD><FONT face="Courier New, Courier" color=#0000ff size=2> 
        <DD>-Jonathan R.</FONT> 
        <DD><BR><BR><FONT size=2>&nbsp;
        <DD>Jonathan D. 
        Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        72 Eagle Rock Ave. 
        <DD>Chief 
        Scientist&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; 
        First Floor 
        <DD>dynamicsoft&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; 
        East Hanover, NJ 07936 
        <DD>jdrosen@dynamicsoft.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        FAX:&nbsp;&nbsp; (973) 952-5050 
        <DD><A 
        href="http://www.cs.columbia.edu/~jdrosen">http://www.cs.columbia.edu/~jdrosen</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        PHONE: (973) 952-5000 
        <DD><A href="http://www.dynamicsoft.com/">http://www.dynamicsoft.com</A> 

        <DD>&nbsp;</FONT> <FONT face=tahoma size=2>
        <DD>-----Original Message----- 
        <DD>From:</B> Rohan Mahy [<A href="mailto:rohan@cisco.com" 
        eudora="autourl">mailto:rohan@cisco.com</A>] 
        <DD>Sent:</B> Monday, January 08, 2001 11:20 AM 
        <DD>To:</B> sip@lists.bell-labs.com 
        <DD>Subject:</B> Re: [SIP] REFER open issues<BR><BR></FONT>
        <DD>Hi,<BR><BR>
        <DD>I've heard some mixed interest at the IETF, and no objections to an 
        interim meeting to build some consensus around REFER open issues.&nbsp; 
        If you are intersted in attending a meeting **and have posted to the 
        list on one of these REFER-related topics**, please indicate your 
        availability and ability to travel to some sample US destinations the 
        last week of January/first week of February by filling in the grid 
        below.&nbsp; an [x] means you are available, a [?] is a maybe.<BR><BR>
        <DD>Of course all the meeting minutes, proposals, etc will get posted 
        back to this list. 
        <DD>Again, please do not spam the whole list with your 
        availability.&nbsp; I'll post a summary.<BR><BR><FONT 
        face="Courier, Courier">
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Please use a fixed-width 
        font such as Courier.<BR><BR>
        <DD>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        Available&nbsp;&nbsp;&nbsp; San Jose&nbsp;&nbsp; Dallas&nbsp;&nbsp; New 
        York&nbsp; RaleighNC&nbsp; Other<BR><BR>
        <DD>Jan 29&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; 
        [ ] 
        <DD>&nbsp;&nbsp;&nbsp; 30&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; 
        [ ] 
        <DD>&nbsp;&nbsp;&nbsp; 31&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; 
        [ ] 
        <DD>Feb&nbsp; 1&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; 
        [ ] 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp; 2&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><BR>
        <DD>&nbsp;&nbsp;&nbsp;&nbsp; 5&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; 
        [ ] 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp; 6&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; 
        [ ] 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp; 7&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; 
        [ ] 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp; 8&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; 
        [ ] 
        <DD>&nbsp;&nbsp;&nbsp;&nbsp; 9&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><BR><BR><BR></FONT>
        <DD>thanks, 
        <DD>-rohan<BR><BR><BR><BR>
        <DD>At 10:08 AM 12/15/00 , Rohan Mahy wrote: 
        <DD>&gt;Hi, 
        <DD>&gt; 
        <DD>&gt;I'd like to summarize ALL the open issues that we have with 
        REFER.&nbsp; In the 
        <DD>&gt;interest of coming to consensus, I'd like to invite interested 
        implementers 
        <DD>&gt;who have comments to meet in person before Minneapolis to close 
        REFER open 
        <DD>&gt;issues.&nbsp; If folks think this is a good idea, we would 
        certainly post the 
        <DD>&gt;minutes and partial consensus back to the list for 
        comments/changes.&nbsp; As a 
        <DD>&gt;strawman, I will suggest sometime in the last week of 
        January.&nbsp; A few 
        <DD>&gt;plausible locations are: Dallas, New York, San Jose...&nbsp; I 
        volunteer to 
        <DD>&gt;organize this if necessary. 
        <DD>&gt; 
        <DD>&gt;A short summary of the issues are below in no particular order: 
        <DD>&gt; 
        <DD>&gt;1) Retransmission problem: 
        <DD>&gt;Robert Sparks already summarized this problem in his recent 
        post. 
        <DD>&gt;(a) REFER completes early, use explicit SUBSCRIBE for more info 
        <DD>&gt;(b) REFER completes early and implicitly SUBSCRIBEs to more info 

        <DD>&gt;(c) REFER completes after 16 secs and provides URL for SUBSCRIBE 

        <DD>&gt;(d) send new REFER (new CSeq same call ID) after 32 seconds. 
        <DD>&gt; 
        <DD>&gt;2) Cancellation: 
        <DD>&gt;If REFER returns a final response before a long INVITE 
        transaction 
        <DD>&gt;completes, how do you cancel that INVITE?&nbsp; 
        <DD>&gt;(a) send same REFER with ;method=CANCEL 
        <DD>&gt;(b) send REFERCANCEL method 
        <DD>&gt; 
        <DD>&gt;3) Call-leg matching: 
        <DD>&gt;Should you include call-id's in Refer-to URLs?&nbsp; If not, 
        what do you use for 
        <DD>&gt;matching (Replaces or similar)? 
        <DD>&gt;(a) match call-ids 
        <DD>&gt;(b) use a Replaces header 
        <DD>&gt;(c) use the mesh-id to setup mesh, then say BYE 
        <DD>&gt;(d) use a new header 
        <DD>&gt; 
        <DD>&gt;4) If we choose Replaces or the like, how do we express that we 
        want to 
        <DD>&gt;*join* 2 legs via REFER? 
        <DD>&gt;(a) Join header 
        <DD>&gt;(b) Associate header 
        <DD>&gt;(c) new method 
        <DD>&gt;(d) something else 
        <DD>&gt; 
        <DD>&gt;5) If Refer-To contains parameters (method, transport), or 
        potentially 
        <DD>&gt;contradictory headers, what do we do with them? 
        <DD>&gt;(a) allow all of them if authorized 
        <DD>&gt;(b) allow a subset of methods/headers 
        <DD>&gt;(c) send an error mesage 
        <DD>&gt;(d) ignore the headers/parameters 
        <DD>&gt;(e) ignore the whole message 
        <DD>&gt; 
        <DD>&gt;6) If we don't allow&nbsp; ;method=BYE, how do we solve the 
        problem described in 
        <DD>&gt;the Music on 
        <DD>&gt;Hold flow? 
        <DD>&gt;(a) method=BYE 
        <DD>&gt;(b) ??? 
        <DD>&gt; 
        <DD>&gt;7) How do we ask devices to do stuff for us?&nbsp; [probably 
        defer this issue] 
        <DD>&gt;(a) REFER with parameters/headers 
        <DD>&gt;(b) PHONECTL 
        <DD>&gt;(c) some NEWMETHOD 
        <DD>&gt;(d) Mbus 
        <DD>&gt;(e) other 
        <DD>&gt; 
        <DD>&gt;Any other REFER open issues I missed? 
        <DD>&gt; 
        <DD>&gt;thanks, 
        <DD>&gt;-rohan 
        <DD>&gt; 
        <DD>&gt; 
        <DD>&gt; 
        <DD>&gt;_______________________________________________ 
        <DD>&gt;SIP mailing list 
        <DD>&gt;SIP@lists.bell-labs.com 
        <DD>&gt;<A href="http://lists.bell-labs.com/mailman/listinfo/sip" 
        eudora="autourl">http://lists.bell-labs.com/mailman/listinfo/sip</A><BR><BR></DD></DL></BLOCKQUOTE><BR></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C07A72.AAF817A0--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 15:04:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20471
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 15:04:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A268244354; Tue,  9 Jan 2001 14:05:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 472D144337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 14:04:44 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f09K23D26934;
	Tue, 9 Jan 2001 14:02:03 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: Christian Huitema <huitema@exchange.microsoft.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Early media replacement.
Message-ID: <20010109140203.A4669@fdd.com>
References: <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9ED@speak.dogfood>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9ED@speak.dogfood>; from huitema@exchange.microsoft.com on Tue, Jan 09, 2001 at 09:28:11AM -0800
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 14:02:03 -0600

On Tue, Jan 09, 2001 at 09:28:11AM -0800, Christian Huitema wrote:
> 
> The second argument is that mixing multiple progress tones is confusing.
> But we definitely want to be able to "ring the five telephones in the
> house and pick the first one that gets lifted." I think that the
> consensus
> here is that having a 183 response does not help one bit. If we have
> multiple simultaneous ringing, the user is probably better off with
> synthesized ringing. So, may be what we need is a rule that says "don't
> send multimedia if you received a forked INVITE."
> 

Five SIP phones?  then there is no problem, unless they
independently go through PSTN gateway B channels,
a terrible design from the start.
SIP phones don't need to send early media because
they know for sure the call state.

The early media problem is PSTN gateways
which do not know the call state.  Please treat the 
disease not the symptom.

--
Rick


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 15:38:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20974
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 15:38:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 317F544338; Tue,  9 Jan 2001 14:39:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 75D9D44337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 14:38:05 -0500 (EST)
Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f09KaJK04968;
	Tue, 9 Jan 2001 14:36:19 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f09KaIa03432;
	Tue, 9 Jan 2001 14:36:18 -0600 (CST)
Received: from ericsson.com (pc050184.exu.ericsson.se [138.85.50.184]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA03654; Tue, 9 Jan 2001 14:36:18 -0600 (CST)
Message-ID: <3A5B764E.5080003@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Sparks <rsparks@dynamicsoft.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] REFER progress
References: <9BF66EBF6BEFD942915B4D4D45C051F30474AB@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 14:36:30 -0600
Content-Transfer-Encoding: 7bit

True. We are quibbling on the method name.
NOTIFY fits the need quite nicely. Why
invent something new? Of course, on the
question of more than one NOTIFY, I see
no reason why it couldn't be done. For
simplicity, I'm willing to start with the
model of a single NOTIFY indicating the
final response of the "referred" transaction.
(No one mention forking and we will all get
through this without a nervous breakdown :)

/sean

Robert Sparks wrote:

> As far as I can thell, You and Sean are assuming you get
> exactly one NOTIFY then. 
> 
> At that point we're just quibbling on the method name.
> 
> Or do you disagree? If you are assuming more than one
> NOTIFY, then I think you missed my point.
> 
> RjS
> 
> 
> 
> 
>> -----Original Message-----
>> From: Rohan Mahy [mailto:rohan@cisco.com]
>> Sent: Tuesday, January 09, 2001 12:50 PM
>> To: Sean Olson; Robert Sparks
>> Cc: sip@lists.bell-labs.com
>> Subject: Re: [SIP] REFER progress
>> 
>> 
>> Hi,
>> 
>> I agree with Sean that an implicit NOTIFY is straightforward, no more
>> complicated than REFERDONE and solves the timeout problem.  I 
>> hope we don't
>> need a meeting to close this issue.  ;-)
>> 
>> The "other" problem, however, is the one that opened the can of worms.
>> What primitive(s) do you use to get attended transfer to 
>> work?  All of the
>> proposals (something like 4 of them) work and solve the 
>> requirement for an
>> attended transfer.  Some of these proposals deal more with 
>> the  bis draft
>> (see Tom Taylor's post today).  Everyone seems to want other 
>> features as
>> well, but we need to see at least a "sketch" of the complete features
>> picture associated with each proposal.  This is why I 
>> proposed the one-day
>> face-to-face meeting.
>> 
>> thanks,
>> -rohan
>> 
>> 
>> 
>> At 12:15 PM 1/9/01 , Sean Olson wrote:
>> 
>>> I'm sorry, I don't see the standardization of the
>>> REFERDONE as being any easier than the standardization
>>> of a NOTIFY to serve the same purpose.
>>> 
>>> To satisfy a need stated by Billy, the
>>> body of the NOTIFY could simply be the SDP
>> 
>> >from the 200 OK (assuming an INVITE) or empty
>> 
>>> for a BYE. Uses of REFER for other methods would
>>> need to be specified in extension drafts.
>>> The Event: token could be "referdone".
>>> 
>>> Is there anything else that needs to be specified
>>> for the use of NOTIFY that I am missing?
>>> 
>>> I don't wish to drag this out forever. I think
>>> the solution is fairly simple and straightforward
>>> and could be extended in the future.
>>> 
>>> Please point out faults with this proposal and
>>> areas of implementation difficulty.
>>> /sean
>>> 
>>> Robert Sparks wrote:
>>> 
>>> 
>>>> a.s. This got a little long - sorry
>>>>      It does contain a concrete proposal.
>>>> ------------
>>>> I think we are falling into a set of traps
>>>> with the REFER discussions, endangering an
>>>> already overdue deliverable.
>>>> 
>>>> The worst is specification creep. The group
>>>> was pretty happy with the functionality of
>>>> the current draft. When we tripped up on the
>>>> timeout problem, we saw a host of extra 
>>>> functionality we could add while working
>>>> around that problem.
>>>> 
>>>> Most of us have gravitated towards a model
>>>> where REFER is answered with a set of
>>>> reciprocal responses (essentially NOTIFYs,
>>>> possibly of a different name, with or without
>>>> an explicit subscribe). What we _haven't_
>>>> spent much time on is the profile of those
>>>> responses. How many can there be? What do
>>>> they contain?
>>>> 
>>>> I really anticipate the answers to those last
>>>> questions will vary widely depending on the
>>>> application using REFER. We want to be able
>>>> to do other things than transfer (this is 
>>>> why the method got renamed from TRANSFER).
>>>> A rich response set for a REFER that triggers
>>>> a SUBSCRIBE is likely to be entirely different
>>>> in character from one that triggers an INVITE.
>>>> 
>>>> 
>>>> PROPOSAL
>>>> In interests of meeting our working group
>>>> deliverable on this topic (now _WAY_ overdue),
>>>> I suggest that obtaining this rich response
>>>> set has shown itself to be too big a bite. I
>>>> propose that it is time to fall back to a single
>>>> REFERDONE reciprocal request, carrying the
>>>> information that is provided in the current
>>>> draft's final response. This would provide a
>>>> baseline version of REFER that would meet the
>>>> requirements the current draft addresses.
>>>> 
>>>> I further propose that when we complete that work,
>>>> we can return to REFER and define an extension that
>>>> would get the richer response set, addressing the
>>>> current lack of definition of that response set
>>>> with something like sip-event profiles.
>>>> 
>>>> RjS
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> SIP mailing list
>>>> SIP@lists.bell-labs.com
>>>> http://lists.bell-labs.com/mailman/listinfo/sip
>>> 
>>> 
>>> _______________________________________________
>>> SIP mailing list
>>> SIP@lists.bell-labs.com
>>> http://lists.bell-labs.com/mailman/listinfo/sip
>> 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 15:45:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21100
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 15:45:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 897344434E; Tue,  9 Jan 2001 14:46:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 0779244338
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 14:45:27 -0500 (EST)
Received: from pn190.warszawa.cvx.ppp.tpnet.pl ([213.76.109.190]:1348 "EHLO
        elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP
	id <S227515AbRAIUo5>; Tue, 9 Jan 2001 21:44:57 +0100
Message-ID: <3A5B76EC.6ECAF5C8@elka.pw.edu.pl>
From: "Piotr S. Kossowski" <P.Kossowski@elka.pw.edu.pl>
Organization: Warsaw University of Technology - Institute of Telecommunications
X-Mailer: Mozilla 4.7 [pl] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: SIP discussion list <sip@lists.bell-labs.com>
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit
Subject: [SIP] different types of URI in 'Contact'
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 21:39:08 +0100
Content-Transfer-Encoding: 7bit

Hello,

I have got simple question:

Say that 'Contact' in 200 OK to INVITE req includes only one URI: mailto.
This is correct according to 'Contact' syntax. Section 11.2 of 
rfc2543bis-2 says that "(...)'Contact' contains address where the callee
would like to be contacted fo subsequent transactions, including the ACK
for the current INVITE". If there is only one URI in the 'Contact' e.g.
'mailto:' or 'http:' , how to send ACK to this destination. From technical
point of view it is easy, but i mean that UAS will never get ACK and
will have to break just-established call because lack of ACK. 
Could you correct me ?

Best Regards, Piotr


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 15:48:06 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21141
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 15:48:06 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5A2C44436A; Tue,  9 Jan 2001 14:47:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lists.bell-labs.com (Postfix) with ESMTP id DB4B34434E
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 14:46:38 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f09KkQC00658
	for <sip@lists.bell-labs.com>; Tue, 9 Jan 2001 21:46:26 +0100 (MET)
Received: from lmf.ericsson.se (E005004B52C74-udp505447.lmf.ericsson.se [131.160.106.10])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id WAA07606
	for <sip@lists.bell-labs.com>; Tue, 9 Jan 2001 22:46:25 +0200 (EET)
Message-ID: <3A5B78A1.3CF425E0@lmf.ericsson.se>
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: multipart/mixed;
 boundary="------------E5CE3C74A9D691D3B5969CB8"
Subject: [SIP] Mix or replace
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 22:46:25 +0200

This is a multi-part message in MIME format.
--------------E5CE3C74A9D691D3B5969CB8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

This issue was mentioned in, and is part of, the early media replacement
thread, but I would like to ask about here.

My question is: If we receive multiple 183 responses, with SDP message
bodies, from different locations, should we:

1. Mix the media streams

...or...

2. Replace the media stream every time we get a new 183 response.

My assumption was option 2, but since Jonathan mentioned the audio
mixing in a previous mail I would like to raise the question.

The problem is that there be cases where one option is to be used, while
in other cases the option is to be used...

Regards,

Christer Holmberg
Ericsson Finland
--------------E5CE3C74A9D691D3B5969CB8
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------E5CE3C74A9D691D3B5969CB8--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 15:54:59 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21249
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 15:54:59 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 084FE44388; Tue,  9 Jan 2001 14:55:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by lists.bell-labs.com (Postfix) with ESMTP id 0233F44386
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 14:54:53 -0500 (EST)
Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com;
          Tue, 9 Jan 2001 15:53:39 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBR0K8>; Tue, 9 Jan 2001 15:53:41 -0500
Message-ID: <28560036253BD41191A10000F8BCBD11034BD1A4@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: Robert Sparks <rsparks@dynamicsoft.com>, "'Rohan Mahy'" <rohan@cisco.com>,
        Sean Olson <sean.olson@ericsson.com>
Cc: sip <sip@lists.bell-labs.com>
Subject: RE: [SIP] REFER progress
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C07A7E.3D9644A0"
X-Orig: <taylor@americasm01.nt.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 15:53:38 -0500

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_01C07A7E.3D9644A0
Content-Type: text/plain;
	charset="iso-8859-1"

I assumed the originator would be subscribed to all of the responses
associated with the transaction, simply as a consequence of piggybacking on
the general SUBS/NOTIFY mechanism as applied to SIP events.

> -----Original Message-----
> From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
> Sent: Tuesday, January 09, 2001 2:24 PM
> To: 'Rohan Mahy'; Sean Olson; Robert Sparks
> Cc: sip
> Subject: RE: [SIP] REFER progress
> 
> 
> As far as I can thell, You and Sean are assuming you get
> exactly one NOTIFY then. 
> 
> At that point we're just quibbling on the method name.
> 
> Or do you disagree? If you are assuming more than one
> NOTIFY, then I think you missed my point.
> 
> RjS
> 
> 
> 
> > -----Original Message-----
> > From: Rohan Mahy [mailto:rohan@cisco.com]
> > Sent: Tuesday, January 09, 2001 12:50 PM
> > To: Sean Olson; Robert Sparks
> > Cc: sip@lists.bell-labs.com
> > Subject: Re: [SIP] REFER progress
> > 
> > 
> > Hi,
> > 
> > I agree with Sean that an implicit NOTIFY is 
> straightforward, no more
> > complicated than REFERDONE and solves the timeout problem.  I 
> > hope we don't
> > need a meeting to close this issue.  ;-)
> > 
> > The "other" problem, however, is the one that opened the 
> can of worms.
> > What primitive(s) do you use to get attended transfer to 
> > work?  All of the
> > proposals (something like 4 of them) work and solve the 
> > requirement for an
> > attended transfer.  Some of these proposals deal more with 
> > the  bis draft
> > (see Tom Taylor's post today).  Everyone seems to want other 
> > features as
> > well, but we need to see at least a "sketch" of the 
> complete features
> > picture associated with each proposal.  This is why I 
> > proposed the one-day
> > face-to-face meeting.
> > 
> > thanks,
> > -rohan
> > 
> > 
> > 
> > At 12:15 PM 1/9/01 , Sean Olson wrote:
> > >I'm sorry, I don't see the standardization of the
> > >REFERDONE as being any easier than the standardization
> > >of a NOTIFY to serve the same purpose.
> > >
> > >To satisfy a need stated by Billy, the
> > >body of the NOTIFY could simply be the SDP
> > >from the 200 OK (assuming an INVITE) or empty
> > >for a BYE. Uses of REFER for other methods would
> > >need to be specified in extension drafts.
> > >The Event: token could be "referdone".
> > >
> > >Is there anything else that needs to be specified
> > >for the use of NOTIFY that I am missing?
> > >
> > >I don't wish to drag this out forever. I think
> > >the solution is fairly simple and straightforward
> > >and could be extended in the future.
> > >
> > >Please point out faults with this proposal and
> > >areas of implementation difficulty.
> > >/sean
> > >
> > >Robert Sparks wrote:
> > >
> > >> a.s. This got a little long - sorry
> > >>      It does contain a concrete proposal.
> > >> ------------
> > >> I think we are falling into a set of traps
> > >> with the REFER discussions, endangering an
> > >> already overdue deliverable.
> > >> 
> > >> The worst is specification creep. The group
> > >> was pretty happy with the functionality of
> > >> the current draft. When we tripped up on the
> > >> timeout problem, we saw a host of extra 
> > >> functionality we could add while working
> > >> around that problem.
> > >> 
> > >> Most of us have gravitated towards a model
> > >> where REFER is answered with a set of
> > >> reciprocal responses (essentially NOTIFYs,
> > >> possibly of a different name, with or without
> > >> an explicit subscribe). What we _haven't_
> > >> spent much time on is the profile of those
> > >> responses. How many can there be? What do
> > >> they contain?
> > >> 
> > >> I really anticipate the answers to those last
> > >> questions will vary widely depending on the
> > >> application using REFER. We want to be able
> > >> to do other things than transfer (this is 
> > >> why the method got renamed from TRANSFER).
> > >> A rich response set for a REFER that triggers
> > >> a SUBSCRIBE is likely to be entirely different
> > >> in character from one that triggers an INVITE.
> > >> 
> > >> 
> > >> PROPOSAL
> > >> In interests of meeting our working group
> > >> deliverable on this topic (now _WAY_ overdue),
> > >> I suggest that obtaining this rich response
> > >> set has shown itself to be too big a bite. I
> > >> propose that it is time to fall back to a single
> > >> REFERDONE reciprocal request, carrying the
> > >> information that is provided in the current
> > >> draft's final response. This would provide a
> > >> baseline version of REFER that would meet the
> > >> requirements the current draft addresses.
> > >> 
> > >> I further propose that when we complete that work,
> > >> we can return to REFER and define an extension that
> > >> would get the richer response set, addressing the
> > >> current lack of definition of that response set
> > >> with something like sip-event profiles.
> > >> 
> > >> RjS
> > >> 
> > >> 
> > >> 
> > >> _______________________________________________
> > >> SIP mailing list
> > >> SIP@lists.bell-labs.com
> > >> http://lists.bell-labs.com/mailman/listinfo/sip
> > >
> > >
> > >_______________________________________________
> > >SIP mailing list
> > >SIP@lists.bell-labs.com
> > >http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

------_=_NextPart_001_01C07A7E.3D9644A0
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [SIP] REFER progress</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I assumed the originator would be subscribed to all =
of the responses associated with the transaction, simply as a =
consequence of piggybacking on the general SUBS/NOTIFY mechanism as =
applied to SIP events.</FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Robert Sparks [<A =
HREF=3D"mailto:rsparks@dynamicsoft.com">mailto:rsparks@dynamicsoft.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, January 09, 2001 2:24 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Rohan Mahy'; Sean Olson; Robert =
Sparks</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: sip</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [SIP] REFER progress</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As far as I can thell, You and Sean are =
assuming you get</FONT>
<BR><FONT SIZE=3D2>&gt; exactly one NOTIFY then. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At that point we're just quibbling on the =
method name.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Or do you disagree? If you are assuming more =
than one</FONT>
<BR><FONT SIZE=3D2>&gt; NOTIFY, then I think you missed my =
point.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; RjS</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; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Rohan Mahy [<A =
HREF=3D"mailto:rohan@cisco.com">mailto:rohan@cisco.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Tuesday, January 09, 2001 12:50 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Sean Olson; Robert Sparks</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: sip@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Re: [SIP] REFER progress</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I agree with Sean that an implicit NOTIFY =
is </FONT>
<BR><FONT SIZE=3D2>&gt; straightforward, no more</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; complicated than REFERDONE and solves the =
timeout problem.&nbsp; I </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; hope we don't</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; need a meeting to close this issue.&nbsp; =
;-)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The &quot;other&quot; problem, however, is =
the one that opened the </FONT>
<BR><FONT SIZE=3D2>&gt; can of worms.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; What primitive(s) do you use to get =
attended transfer to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; work?&nbsp; All of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; proposals (something like 4 of them) work =
and solve the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; requirement for an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; attended transfer.&nbsp; Some of these =
proposals deal more with </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the&nbsp; bis draft</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (see Tom Taylor's post today).&nbsp; =
Everyone seems to want other </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; features as</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; well, but we need to see at least a =
&quot;sketch&quot; of the </FONT>
<BR><FONT SIZE=3D2>&gt; complete features</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; picture associated with each =
proposal.&nbsp; This is why I </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; proposed the one-day</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; face-to-face meeting.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -rohan</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; At 12:15 PM 1/9/01 , Sean Olson =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;I'm sorry, I don't see the =
standardization of the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;REFERDONE as being any easier than the =
standardization</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;of a NOTIFY to serve the same =
purpose.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;To satisfy a need stated by Billy, =
the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;body of the NOTIFY could simply be the =
SDP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;from the 200 OK (assuming an INVITE) =
or empty</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;for a BYE. Uses of REFER for other =
methods would</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;need to be specified in extension =
drafts.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;The Event: token could be =
&quot;referdone&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Is there anything else that needs to =
be specified</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;for the use of NOTIFY that I am =
missing?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;I don't wish to drag this out forever. =
I think</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;the solution is fairly simple and =
straightforward</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;and could be extended in the =
future.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Please point out faults with this =
proposal and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;areas of implementation =
difficulty.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;/sean</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;Robert Sparks wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; a.s. This got a little long - =
sorry</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It =
does contain a concrete proposal.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; ------------</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; I think we are falling into a set =
of traps</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; with the REFER discussions, =
endangering an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; already overdue =
deliverable.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; The worst is specification creep. =
The group</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; was pretty happy with the =
functionality of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; the current draft. When we =
tripped up on the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; timeout problem, we saw a host of =
extra </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; functionality we could add while =
working</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; around that problem.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; Most of us have gravitated =
towards a model</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; where REFER is answered with a =
set of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; reciprocal responses (essentially =
NOTIFYs,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; possibly of a different name, =
with or without</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; an explicit subscribe). What we =
_haven't_</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; spent much time on is the profile =
of those</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; responses. How many can there be? =
What do</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; they contain?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; I really anticipate the answers =
to those last</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; questions will vary widely =
depending on the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; application using REFER. We want =
to be able</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; to do other things than transfer =
(this is </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; why the method got renamed from =
TRANSFER).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; A rich response set for a REFER =
that triggers</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; a SUBSCRIBE is likely to be =
entirely different</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; in character from one that =
triggers an INVITE.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; PROPOSAL</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; In interests of meeting our =
working group</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; deliverable on this topic (now =
_WAY_ overdue),</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; I suggest that obtaining this =
rich response</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; set has shown itself to be too =
big a bite. I</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; propose that it is time to fall =
back to a single</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; REFERDONE reciprocal request, =
carrying the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; information that is provided in =
the current</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; draft's final response. This =
would provide a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; baseline version of REFER that =
would meet the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; requirements the current draft =
addresses.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; I further propose that when we =
complete that work,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; we can return to REFER and define =
an extension that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; would get the richer response =
set, addressing the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; current lack of definition of =
that response set</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; with something like sip-event =
profiles.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; RjS</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; SIP mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; SIP@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&gt; <A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/sip" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></F=
ONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
&gt;_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;SIP mailing list</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;SIP@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;<A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/sip" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></F=
ONT>
<BR><FONT SIZE=3D2>&gt; &gt; </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</FONT>
<BR><FONT SIZE=3D2>&gt; SIP@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/sip" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></F=
ONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07A7E.3D9644A0--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 15:59:34 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21297
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 15:59:33 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BB81F4439E; Tue,  9 Jan 2001 14:57:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15])
	by lists.bell-labs.com (Postfix) with ESMTP id EA1A444388
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 14:56:36 -0500 (EST)
Received: from zrchb200.us.nortel.com (actually zrchb200) 
          by smtprch2.nortel.com; Tue, 9 Jan 2001 14:51:37 -0600
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <Z8FF4G3L>; Tue, 9 Jan 2001 14:56:13 -0600
Message-ID: <85AA7486A2C1D411BCA20000F8073E43BAADED@crchy271.us.nortel.com>
From: "Brian Stucker" <bstucker@nortelnetworks.com>
To: "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
Subject: RE: [SIP] Discussion of Default Timers
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C07A7E.997AE550"
X-Orig: <bstucker@americasm01.nt.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 14:56:12 -0600

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_01C07A7E.997AE550
Content-Type: text/plain;
	charset="iso-8859-1"

Any thoughts on this from anyone? I really do think this would be something
useful to add to the specification to help SIP networks deal with traffic
conditions, network latentcy, etc. in a very effective and targeted manner
without much complexity.
 
Brian

-----Original Message-----
From: Stucker, Brian [RICH2:WI41:EXCH] 
Sent: Wednesday, January 03, 2001 3:47 PM
To: Sean Olson; Dean Willis
Cc: IETF SIP (E-mail)
Subject: RE: [SIP] Discussion of Default Timers



Ah... Should have read further back into the thread than I did. 

If I read 2543 correctly, it already allows for timers on the clients to be
autonomously extended (but not shortened) by the client without any server
interaction.

I guess I would recommend that we consider adding the following (along the
lines of the retry-after header): 

----<snippet start>---- 

response-header ... 
                | Context-Timers 


Header field              where       proxy ACK BYE CAN INV OPT REG 
------------------------------------------------------------------- 
Context-Timers           100,18x        -    -   -   -   o   -   o 


Context-Timers 

The Context-Timers response-header field MAY be included to RECOMMEND to a
client or server on a per-hop, per context basis, to use timer values
different than the default SIP values on a 1xx response from an INVITE.
These timers would then be considered to be in effect for the remainder of
that call context. The remaining time left of any pending timers upon
processing the response would be deducted from the values specified in the
response, and the timers updated with the result.

Additionally, this response-header MAY also be included as part of a final
200 response to a REGISTER in order to update the timer lengths
semi-permanently over all call contexts for that registration period. Timers
received in 1xx class responses take precendence over those received in
response to a registration.

Context-Timers = "Context-Timers" ":" (( 1# (Timer-name "=" length) )
*(";")) 

timer-name = RFC defined timer string 
length = timer interval in ms. 

Example: 

Context-Timers: T1=800;T2=1200 

Would update timers T1 and T2 to 800ms, and 1200ms, respectively. Note, that
if the length of the timer specified is SHORTER than the default minimums
specified in the RFC, that the value is discarded and ignored.



----<snippet end>---- 

Start throwing darts... I would think this sort of arrangement would keep
everyone happy by letting them have their proxies tell the subtending UAs
whatever values are appropriate to use in that network at that moment
(perhaps even for that particular call). For instance, if the proxy knows
that it's slow, or that it's going to have to go off and do something
special with this request, it can tell the UA to hold on a bit longer than
normal. If the network architecture itself is slower (wireless access) then
it can tell UAs who might have migrated from a LAN connection that they need
to give the system a bit more time to do things now, etc...

Again, off the top of my head, so if there's errors in the syntax or
reasoning, I'm not surprised. Just throwing something out there for
consideration.

Brian Stucker 
Nortel Networks 



-----Original Message----- 
From: Sean Olson [ mailto:sean.olson@ericsson.com
<mailto:sean.olson@ericsson.com> ] 
Sent: Tuesday, January 02, 2001 11:55 AM 
To: Dean Willis 
Cc: IETF SIP (E-mail) 
Subject: Re: [SIP] Discussion of Default Timers 


I agree that this is a problem and it is aggravated in the 
case of wireless access where latencies are even larger. 

Regarding the alternatives you list: 

1) Faster proxies -- this is basically chasing rainbows. The processing 
   delay can only be cut down so much and it is prone to break when 
   new topologies introduce additional proxies 

2) More statefull proxies -- This seems like a reasonable approach 
   for many deployments (enterprise and GSTN gateways in particular) 
   but of course can't be fixed by standardization, i.e. we can't 
   mandate this (at least in the SIP spec) 

3) Changing the default timers -- I like this approach but I think 
   it isn't realistic given the current implementations. How many 
   implementations hard-code this value I wonder? 

I would recommend a combination of alternatives 2 and 3 for 
most architectures. Perhaps this could be part of a larger set 
of recommendations in a BCP? 

/sean 

Dean Willis wrote: 
> 
> I've started to wonder about the retransmission timers recommended in
2543. 
> 
> The basic assumption is that VoIP networks will have round-trip times of 
> less than 500ms. This seems to be a valid assumptio for the medai path,
but 
> remember -- with SIP, the SIGNALING path is not necessarily thesame as the

> MEDIA path. And the timers apply to the SIGNALING path. 
> 
> Many of the architectures I'm seeing have three thousand kilometers, ten 
> routers, and six proxies between two SIP endpoints.  Assuming 6ms/1000km, 
> 10ms/router, and 50ms/proxy, that works out to 418ms each way, or a total
of 
> 836ms round trip. With default settings, the originating UA is going to 
> resend its INVITE after only 500ms unless response is received. Everybody 
> wants to use stateless proxies for performance reaons. So, nearly every 
> INVITE gets sent twice. This can be severely detrimental to the function
of 
> a proxy that is operating at near peak capacity -- in fact, it basically 
> cuts the peak capacity of a proxy in half whenever proxy chains are 
> configured in such a way that T1 is regularly exceeded. 
> 
> There are a couple of alternatives that come to mind: 
> 
> 1) Deploy faster proxies. 
> 2) Deploy 100-generating proxies at all levels to prevent timer expiration

> due to downstream latency. 
> 3) Change the default timers. 
> 
> Thoughts? 
> 
> -- 
> Dean Willis 
> 
> _______________________________________________ 
> SIP mailing list 
> SIP@lists.bell-labs.com 
> http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>  

_______________________________________________ 
SIP mailing list 
SIP@lists.bell-labs.com 
http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>  


------_=_NextPart_001_01C07A7E.997AE550
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [SIP] Discussion of Default Timers</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=212255420-09012001>Any 
thoughts on this from anyone? I really do think this would be something useful 
to add to the specification to help SIP networks deal with traffic conditions, 
network latentcy, etc. in a very effective and targeted manner without much 
complexity.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=212255420-09012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=212255420-09012001>Brian</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Stucker, Brian 
  [RICH2:WI41:EXCH] <BR><B>Sent:</B> Wednesday, January 03, 2001 3:47 
  PM<BR><B>To:</B> Sean Olson; Dean Willis<BR><B>Cc:</B> IETF SIP 
  (E-mail)<BR><B>Subject:</B> RE: [SIP] Discussion of Default 
  Timers<BR><BR></DIV></FONT>
  <P><FONT size=2>Ah... Should have read further back into the thread than I 
  did.</FONT> </P>
  <P><FONT size=2>If I read 2543 correctly, it already allows for timers on the 
  clients to be autonomously extended (but not shortened) by the client without 
  any server interaction.</FONT></P>
  <P><FONT size=2>I guess I would recommend that we consider adding the 
  following (along the lines of the retry-after header):</FONT> </P>
  <P><FONT size=2>----&lt;snippet start&gt;----</FONT> </P>
  <P><FONT size=2>response-header ...</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  | Context-Timers</FONT> </P><BR>
  <P><FONT size=2>Header 
  field&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  where&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; proxy ACK BYE CAN INV OPT REG</FONT> 
  <BR><FONT 
  size=2>-------------------------------------------------------------------</FONT> 
  <BR><FONT 
  size=2>Context-Timers&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  100,18x&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -&nbsp;&nbsp;&nbsp; 
  -&nbsp;&nbsp; -&nbsp;&nbsp; -&nbsp;&nbsp; o&nbsp;&nbsp; -&nbsp;&nbsp; o</FONT> 
  </P><BR>
  <P><FONT size=2>Context-Timers</FONT> </P>
  <P><FONT size=2>The Context-Timers response-header field MAY be included to 
  RECOMMEND to a client or server on a per-hop, per context basis, to use timer 
  values different than the default SIP values on a 1xx response from an INVITE. 
  These timers would then be considered to be in effect for the remainder of 
  that call context. The remaining time left of any pending timers upon 
  processing the response would be deducted from the values specified in the 
  response, and the timers updated with the result.</FONT></P>
  <P><FONT size=2>Additionally, this response-header MAY also be included as 
  part of a final 200 response to a REGISTER in order to update the timer 
  lengths semi-permanently over all call contexts for that registration period. 
  Timers received in 1xx class responses take precendence over those received in 
  response to a registration.</FONT></P>
  <P><FONT size=2>Context-Timers = "Context-Timers" ":" (( 1# (Timer-name "=" 
  length) ) *(";"))</FONT> </P>
  <P><FONT size=2>timer-name = RFC defined timer string</FONT> <BR><FONT 
  size=2>length = timer interval in ms.</FONT> </P>
  <P><FONT size=2>Example:</FONT> </P>
  <P><FONT size=2>Context-Timers: T1=800;T2=1200</FONT> </P>
  <P><FONT size=2>Would update timers T1 and T2 to 800ms, and 1200ms, 
  respectively. Note, that if the length of the timer specified is SHORTER than 
  the default minimums specified in the RFC, that the value is discarded and 
  ignored.</FONT></P><BR><BR>
  <P><FONT size=2>----&lt;snippet end&gt;----</FONT> </P>
  <P><FONT size=2>Start throwing darts... I would think this sort of arrangement 
  would keep everyone happy by letting them have their proxies tell the 
  subtending UAs whatever values are appropriate to use in that network at that 
  moment (perhaps even for that particular call). For instance, if the proxy 
  knows that it's slow, or that it's going to have to go off and do something 
  special with this request, it can tell the UA to hold on a bit longer than 
  normal. If the network architecture itself is slower (wireless access) then it 
  can tell UAs who might have migrated from a LAN connection that they need to 
  give the system a bit more time to do things now, etc...</FONT></P>
  <P><FONT size=2>Again, off the top of my head, so if there's errors in the 
  syntax or reasoning, I'm not surprised. Just throwing something out there for 
  consideration.</FONT></P>
  <P><FONT size=2>Brian Stucker</FONT> <BR><FONT size=2>Nortel Networks</FONT> 
  </P><BR><BR>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Sean 
  Olson [<A 
  href="mailto:sean.olson@ericsson.com">mailto:sean.olson@ericsson.com</A>]</FONT> 
  <BR><FONT size=2>Sent: Tuesday, January 02, 2001 11:55 AM</FONT> <BR><FONT 
  size=2>To: Dean Willis</FONT> <BR><FONT size=2>Cc: IETF SIP (E-mail)</FONT> 
  <BR><FONT size=2>Subject: Re: [SIP] Discussion of Default Timers</FONT> 
  </P><BR>
  <P><FONT size=2>I agree that this is a problem and it is aggravated in 
  the</FONT> <BR><FONT size=2>case of wireless access where latencies are even 
  larger.</FONT> </P>
  <P><FONT size=2>Regarding the alternatives you list:</FONT> </P>
  <P><FONT size=2>1) Faster proxies -- this is basically chasing rainbows. The 
  processing</FONT> <BR><FONT size=2>&nbsp;&nbsp; delay can only be cut down so 
  much and it is prone to break when</FONT> <BR><FONT size=2>&nbsp;&nbsp; new 
  topologies introduce additional proxies</FONT> </P>
  <P><FONT size=2>2) More statefull proxies -- This seems like a reasonable 
  approach</FONT> <BR><FONT size=2>&nbsp;&nbsp; for many deployments (enterprise 
  and GSTN gateways in particular)</FONT> <BR><FONT size=2>&nbsp;&nbsp; but of 
  course can't be fixed by standardization, i.e. we can't</FONT> <BR><FONT 
  size=2>&nbsp;&nbsp; mandate this (at least in the SIP spec)</FONT> </P>
  <P><FONT size=2>3) Changing the default timers -- I like this approach but I 
  think</FONT> <BR><FONT size=2>&nbsp;&nbsp; it isn't realistic given the 
  current implementations. How many</FONT> <BR><FONT size=2>&nbsp;&nbsp; 
  implementations hard-code this value I wonder?</FONT> </P>
  <P><FONT size=2>I would recommend a combination of alternatives 2 and 3 for 
  </FONT><BR><FONT size=2>most architectures. Perhaps this could be part of a 
  larger set</FONT> <BR><FONT size=2>of recommendations in a BCP?</FONT> </P>
  <P><FONT size=2>/sean</FONT> </P>
  <P><FONT size=2>Dean Willis wrote:</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; I've started to wonder about the retransmission 
  timers recommended in 2543.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; The basic assumption is that VoIP networks will have round-trip 
  times of</FONT> <BR><FONT size=2>&gt; less than 500ms. This seems to be a 
  valid assumptio for the medai path, but</FONT> <BR><FONT size=2>&gt; remember 
  -- with SIP, the SIGNALING path is not necessarily thesame as the</FONT> 
  <BR><FONT size=2>&gt; MEDIA path. And the timers apply to the SIGNALING 
  path.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Many of the 
  architectures I'm seeing have three thousand kilometers, ten</FONT> <BR><FONT 
  size=2>&gt; routers, and six proxies between two SIP endpoints.&nbsp; Assuming 
  6ms/1000km,</FONT> <BR><FONT size=2>&gt; 10ms/router, and 50ms/proxy, that 
  works out to 418ms each way, or a total of</FONT> <BR><FONT size=2>&gt; 836ms 
  round trip. With default settings, the originating UA is going to</FONT> 
  <BR><FONT size=2>&gt; resend its INVITE after only 500ms unless response is 
  received. Everybody</FONT> <BR><FONT size=2>&gt; wants to use stateless 
  proxies for performance reaons. So, nearly every</FONT> <BR><FONT size=2>&gt; 
  INVITE gets sent twice. This can be severely detrimental to the function 
  of</FONT> <BR><FONT size=2>&gt; a proxy that is operating at near peak 
  capacity -- in fact, it basically</FONT> <BR><FONT size=2>&gt; cuts the peak 
  capacity of a proxy in half whenever proxy chains are</FONT> <BR><FONT 
  size=2>&gt; configured in such a way that T1 is regularly exceeded.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; There are a couple of 
  alternatives that come to mind:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; 1) Deploy faster proxies.</FONT> <BR><FONT size=2>&gt; 2) Deploy 
  100-generating proxies at all levels to prevent timer expiration</FONT> 
  <BR><FONT size=2>&gt; due to downstream latency.</FONT> <BR><FONT size=2>&gt; 
  3) Change the default timers.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; Thoughts?</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; --</FONT> <BR><FONT size=2>&gt; Dean Willis</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  SIP mailing list</FONT> <BR><FONT size=2>&gt; SIP@lists.bell-labs.com</FONT> 
  <BR><FONT size=2>&gt; <A 
  href="http://lists.bell-labs.com/mailman/listinfo/sip" 
  target=_blank>http://lists.bell-labs.com/mailman/listinfo/sip</A></FONT> </P>
  <P><FONT size=2>_______________________________________________</FONT> 
  <BR><FONT size=2>SIP mailing list</FONT> <BR><FONT 
  size=2>SIP@lists.bell-labs.com</FONT> <BR><FONT size=2><A 
  href="http://lists.bell-labs.com/mailman/listinfo/sip" 
  target=_blank>http://lists.bell-labs.com/mailman/listinfo/sip</A></FONT> 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C07A7E.997AE550--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 16:15:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21494
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 16:15:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 014A04433B; Tue,  9 Jan 2001 15:16:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 0B99E4433A
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 15:15:56 -0500 (EST)
Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f09LFaK00350;
	Tue, 9 Jan 2001 15:15:36 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f09LFZa13341;
	Tue, 9 Jan 2001 15:15:35 -0600 (CST)
Received: from ericsson.com (pc050184.exu.ericsson.se [138.85.50.184]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA05808; Tue, 9 Jan 2001 15:15:35 -0600 (CST)
Message-ID: <3A5B7F82.2090004@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: "Piotr S. Kossowski" <P.Kossowski@elka.pw.edu.pl>
Cc: SIP discussion list <sip@lists.bell-labs.com>
Subject: Re: [SIP] different types of URI in 'Contact'
References: <3A5B76EC.6ECAF5C8@elka.pw.edu.pl>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 15:15:46 -0600
Content-Transfer-Encoding: 7bit

Sending an INVITE with only a mailto: URI in the
Contact: header(s) is an error situation. The
purpose of allowing multiple URI types in Contact:
is really to accommodate their use in redirect (3xx)
responses. A 302 with a Contact: header containing a
mailto: URI would, for example, indicate that the
user is reachable via e-mail at this address. To
actually contact that user via e-mail, I wouldn't
send a SIP INVITE of course. I would use SMTP.
Make sense?

/sean

Piotr S. Kossowski wrote:

> Hello,
> 
> I have got simple question:
> 
> Say that 'Contact' in 200 OK to INVITE req includes only one URI: mailto.
> This is correct according to 'Contact' syntax. Section 11.2 of 
> rfc2543bis-2 says that "(...)'Contact' contains address where the callee
> would like to be contacted fo subsequent transactions, including the ACK
> for the current INVITE". If there is only one URI in the 'Contact' e.g.
> 'mailto:' or 'http:' , how to send ACK to this destination. From technical
> point of view it is easy, but i mean that UAS will never get ACK and
> will have to break just-established call because lack of ACK. 
> Could you correct me ?
> 
> Best Regards, Piotr
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 16:28:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21670
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 16:28:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0378944346; Tue,  9 Jan 2001 15:29:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by lists.bell-labs.com (Postfix) with ESMTP id BEDD944340
	for <SIP@lists.bell-labs.com>; Tue,  9 Jan 2001 15:28:39 -0500 (EST)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 9 Jan 2001 16:24:37 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <CGNBSA2D>; Tue, 9 Jan 2001 16:24:38 -0500
Message-ID: <353093573B82D411889E0000F808216648E5EC@zcard00q.ca.nortel.com>
From: "Peter Blatherwick" <blather@nortelnetworks.com>
To: "'Madhubabu Brahmanapally'" <madhubabu@kenetec.com>,
        SIP <SIP@lists.bell-labs.com>
Subject: RE: [SIP] Small Query.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C07A82.8F94BA80"
X-Orig: <blather@americasm01.nt.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 16:24:33 -0500

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_01C07A82.8F94BA80
Content-Type: text/plain;
	charset="iso-8859-1"

Madhu,  

Have a look at
http://www.nortelnetworks.com/products/library/collateral/56025.25-12-00.pdf
, which compares the relative roles of SIP and Megaco/H.248 open standards,
and goes into a bit of detail on how Megaco/H.248 works.  (Sorry in advance
for the slightly marketing flavor ;-) 

Key points:
- SIP is a peer-peer protocol for call (and other media session) control.
Also being considered for several similar peer-peer type applications.  
- Megaco/H.248 is a master/slave protocol which allows network edge
"gateway" entities to be decomposed into media gateway controller (MGC) and
media gateway (MG) parts, with the MG part being a completely dumb slave in
the application sense.  It is orthogonal to the peer-peer protocol used
between the controller entities (controller entities could use SIP, H.323 or
whatever to talk to each other, with Megaco/H.248 used underneath for slave
gateway control).  
- SIP and Megaco/H.248 are completely compatible in the same network, and
solve complementary aspects of the overall network design.  

Hope that helps, 
Peter Blatherwick


-----Original Message-----
From: Madhubabu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Monday, January 08, 2001 10:51
To: SIP
Subject: [SIP] Small Query.


Hi list,henry,rosenberg,

Iam new to SIP. Can any one help me finding (whitepapers,presenatations
,etc..) the differences between SIP and MGCP or H.248. As its not clear why
SIP cannot be used between MG and MGC. SIP appears to have the similar
client-server relationship except for the  additional addressing capability?

Madhu


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C07A82.8F94BA80
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [SIP] Small Query.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Madhu,&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Have a look at <A =
HREF=3D"http://www.nortelnetworks.com/products/library/collateral/56025.=
25-12-00.pdf" =
TARGET=3D"_blank">http://www.nortelnetworks.com/products/library/collate=
ral/56025.25-12-00.pdf</A>, which compares the relative roles of SIP =
and Megaco/H.248 open standards,&nbsp; and goes into a bit of detail on =
how Megaco/H.248 works.&nbsp; (Sorry in advance for the slightly =
marketing flavor ;-) </FONT></P>

<P><FONT SIZE=3D2>Key points:</FONT>
<BR><FONT SIZE=3D2>- SIP is a peer-peer protocol for call (and other =
media session) control.&nbsp; Also being considered for several similar =
peer-peer type applications.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>- Megaco/H.248 is a master/slave protocol which =
allows network edge &quot;gateway&quot; entities to be decomposed into =
media gateway controller (MGC) and media gateway (MG) parts, with the =
MG part being a completely dumb slave in the application sense.&nbsp; =
It is orthogonal to the peer-peer protocol used between the controller =
entities (controller entities could use SIP, H.323 or whatever to talk =
to each other, with Megaco/H.248 used underneath for slave gateway =
control).&nbsp; </FONT></P>

<P><FONT SIZE=3D2>- SIP and Megaco/H.248 are completely compatible in =
the same network, and solve complementary aspects of the overall =
network design.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Hope that helps, </FONT>
<BR><FONT SIZE=3D2>Peter Blatherwick</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Madhubabu Brahmanapally [<A =
HREF=3D"mailto:madhubabu@kenetec.com">mailto:madhubabu@kenetec.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Monday, January 08, 2001 10:51</FONT>
<BR><FONT SIZE=3D2>To: SIP</FONT>
<BR><FONT SIZE=3D2>Subject: [SIP] Small Query.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi list,henry,rosenberg,</FONT>
</P>

<P><FONT SIZE=3D2>Iam new to SIP. Can any one help me finding =
(whitepapers,presenatations</FONT>
<BR><FONT SIZE=3D2>,etc..) the differences between SIP and MGCP or =
H.248. As its not clear why</FONT>
<BR><FONT SIZE=3D2>SIP cannot be used between MG and MGC. SIP appears =
to have the similar</FONT>
<BR><FONT SIZE=3D2>client-server relationship except for the&nbsp; =
additional addressing capability?</FONT>
</P>

<P><FONT SIZE=3D2>Madhu</FONT>
</P>
<BR>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>SIP mailing list</FONT>
<BR><FONT SIZE=3D2>SIP@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/sip" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></F=
ONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C07A82.8F94BA80--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 17:29:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22358
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 17:29:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9F48F4433A; Tue,  9 Jan 2001 16:30:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 7E7BB44337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 16:29:24 -0500 (EST)
Received: from CINQUECENTO ([63.110.3.227])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id RAA26239;
	Tue, 9 Jan 2001 17:08:42 -0500 (EST)
From: "Robert Sparks" <rsparks@dynamicsoft.com>
To: "'Tom-PT Taylor'" <taylor@nortelnetworks.com>,
        "Robert Sparks" <rsparks@dynamicsoft.com>,
        "'Rohan Mahy'" <rohan@cisco.com>,
        "Sean Olson" <sean.olson@ericsson.com>
Cc: "sip" <sip@lists.bell-labs.com>
Subject: RE: [SIP] REFER progress
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30474B1@DYN-TX-EXCH-001.dynamicsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0000_01C07A55.A1123DF0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <28560036253BD41191A10000F8BCBD11034BD1A4@zcard00g.ca.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 16:02:51 -0600

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C07A55.A1123DF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

If you have enough of the SUB/NOTIFY mechanism to include an event
header, you can create profiles on the event that will tell you what
the many NOTIFYs coming back mean. I again argue that to go down
this path sanely, you want an explicit subscribe to a particular event.

Now - to push again for closure of the work item at hand.

Allowing more than one NOTIFY is probably solvable, but is
going to take a _lot_ of discussion. If we restrict the behavior
to one reciprocal request, and call it NOTIFY, we close
the door on allowing more than one NOTIFY in the future.

Hence I push again for REFERDONE. That gets us to where we
thought we were with NOTIFY before we ran afoul of the timeout
problem. This will satisfy the working group deliverable.

_Future_ work can work add notifies to the scenario by extension,
preferably in the context of SIP Events.


RjS

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, January 09, 2001 2:54 PM
To: Robert Sparks; 'Rohan Mahy'; Sean Olson
Cc: sip
Subject: RE: [SIP] REFER progress



I assumed the originator would be subscribed to all of the responses
associated with the transaction, simply as a consequence of piggybacking on
the general SUBS/NOTIFY mechanism as applied to SIP events.

> -----Original Message-----
> From: Robert Sparks [ mailto:rsparks@dynamicsoft.com]
> Sent: Tuesday, January 09, 2001 2:24 PM
> To: 'Rohan Mahy'; Sean Olson; Robert Sparks
> Cc: sip
> Subject: RE: [SIP] REFER progress
>
>
> As far as I can thell, You and Sean are assuming you get
> exactly one NOTIFY then.
>
> At that point we're just quibbling on the method name.
>
> Or do you disagree? If you are assuming more than one
> NOTIFY, then I think you missed my point.
>
> RjS
>
>
>
> > -----Original Message-----
> > From: Rohan Mahy [ mailto:rohan@cisco.com]
> > Sent: Tuesday, January 09, 2001 12:50 PM
> > To: Sean Olson; Robert Sparks
> > Cc: sip@lists.bell-labs.com
> > Subject: Re: [SIP] REFER progress
> >
> >
> > Hi,
> >
> > I agree with Sean that an implicit NOTIFY is
> straightforward, no more
> > complicated than REFERDONE and solves the timeout problem.  I
> > hope we don't
> > need a meeting to close this issue.  ;-)
> >
> > The "other" problem, however, is the one that opened the
> can of worms.
> > What primitive(s) do you use to get attended transfer to
> > work?  All of the
> > proposals (something like 4 of them) work and solve the
> > requirement for an
> > attended transfer.  Some of these proposals deal more with
> > the  bis draft
> > (see Tom Taylor's post today).  Everyone seems to want other
> > features as
> > well, but we need to see at least a "sketch" of the
> complete features
> > picture associated with each proposal.  This is why I
> > proposed the one-day
> > face-to-face meeting.
> >
> > thanks,
> > -rohan
> >
> >
> >
> > At 12:15 PM 1/9/01 , Sean Olson wrote:
> > >I'm sorry, I don't see the standardization of the
> > >REFERDONE as being any easier than the standardization
> > >of a NOTIFY to serve the same purpose.
> > >
> > >To satisfy a need stated by Billy, the
> > >body of the NOTIFY could simply be the SDP
> > >from the 200 OK (assuming an INVITE) or empty
> > >for a BYE. Uses of REFER for other methods would
> > >need to be specified in extension drafts.
> > >The Event: token could be "referdone".
> > >
> > >Is there anything else that needs to be specified
> > >for the use of NOTIFY that I am missing?
> > >
> > >I don't wish to drag this out forever. I think
> > >the solution is fairly simple and straightforward
> > >and could be extended in the future.
> > >
> > >Please point out faults with this proposal and
> > >areas of implementation difficulty.
> > >/sean
> > >
> > >Robert Sparks wrote:
> > >
> > >> a.s. This got a little long - sorry
> > >>      It does contain a concrete proposal.
> > >> ------------
> > >> I think we are falling into a set of traps
> > >> with the REFER discussions, endangering an
> > >> already overdue deliverable.
> > >>
> > >> The worst is specification creep. The group
> > >> was pretty happy with the functionality of
> > >> the current draft. When we tripped up on the
> > >> timeout problem, we saw a host of extra
> > >> functionality we could add while working
> > >> around that problem.
> > >>
> > >> Most of us have gravitated towards a model
> > >> where REFER is answered with a set of
> > >> reciprocal responses (essentially NOTIFYs,
> > >> possibly of a different name, with or without
> > >> an explicit subscribe). What we _haven't_
> > >> spent much time on is the profile of those
> > >> responses. How many can there be? What do
> > >> they contain?
> > >>
> > >> I really anticipate the answers to those last
> > >> questions will vary widely depending on the
> > >> application using REFER. We want to be able
> > >> to do other things than transfer (this is
> > >> why the method got renamed from TRANSFER).
> > >> A rich response set for a REFER that triggers
> > >> a SUBSCRIBE is likely to be entirely different
> > >> in character from one that triggers an INVITE.
> > >>
> > >>
> > >> PROPOSAL
> > >> In interests of meeting our working group
> > >> deliverable on this topic (now _WAY_ overdue),
> > >> I suggest that obtaining this rich response
> > >> set has shown itself to be too big a bite. I
> > >> propose that it is time to fall back to a single
> > >> REFERDONE reciprocal request, carrying the
> > >> information that is provided in the current
> > >> draft's final response. This would provide a
> > >> baseline version of REFER that would meet the
> > >> requirements the current draft addresses.
> > >>
> > >> I further propose that when we complete that work,
> > >> we can return to REFER and define an extension that
> > >> would get the richer response set, addressing the
> > >> current lack of definition of that response set
> > >> with something like sip-event profiles.
> > >>
> > >> RjS
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> SIP mailing list
> > >> SIP@lists.bell-labs.com
> > >> http://lists.bell-labs.com/mailman/listinfo/sip
> > >
> > >
> > >_______________________________________________
> > >SIP mailing list
> > >SIP@lists.bell-labs.com
> > > http://lists.bell-labs.com/mailman/listinfo/sip
> >
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>


------=_NextPart_000_0000_01C07A55.A1123DF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: [SIP] REFER progress</TITLE>

<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D047275221-09012001>If you=20
have enough of the SUB/NOTIFY mechanism to include an =
event</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D047275221-09012001>header, you can create profiles on the event =
that will=20
tell you what</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D047275221-09012001>the=20
many NOTIFYs coming back mean. I again argue that to go =
down</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D047275221-09012001>this=20
path sanely, you want an explicit subscribe to a particular=20
event.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D047275221-09012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D047275221-09012001>Now -=20
to push again for closure of the work item at hand.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D047275221-09012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D047275221-09012001>Allowing more than one NOTIFY is probably =
solvable, but=20
is</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D047275221-09012001>going=20
to take a _lot_ of discussion. If we restrict the =
behavior</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D047275221-09012001>to one=20
reciprocal request, and call it NOTIFY, we close</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D047275221-09012001>the=20
door on allowing more than one NOTIFY in the future.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D047275221-09012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D047275221-09012001>Hence=20
I push again for REFERDONE. That gets us to where we</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D047275221-09012001>thought we were with NOTIFY before we ran =
afoul of the=20
timeout</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D047275221-09012001>problem. This will satisfy the working group=20
deliverable.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D047275221-09012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D047275221-09012001>_Future_ work can work add notifies to the =
scenario by=20
extension,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D047275221-09012001>preferably in the </SPAN></FONT><FONT =
color=3D#0000ff=20
face=3DArial size=3D2><SPAN class=3D047275221-09012001>context of SIP=20
Events.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D047275221-09012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D047275221-09012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D047275221-09012001>RjS</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Tom-PT Taylor=20
  [mailto:taylor@nortelnetworks.com]<BR><B>Sent:</B> Tuesday, January =
09, 2001=20
  2:54 PM<BR><B>To:</B> Robert Sparks; 'Rohan Mahy'; Sean =
Olson<BR><B>Cc:</B>=20
  sip<BR><B>Subject:</B> RE: [SIP] REFER progress<BR><BR></DIV></FONT>
  <P><FONT size=3D2>I assumed the originator would be subscribed to all =
of the=20
  responses associated with the transaction, simply as a consequence of=20
  piggybacking on the general SUBS/NOTIFY mechanism as applied to SIP=20
  events.</FONT></P>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: Robert Sparks [<A=20
  =
href=3D"mailto:rsparks@dynamicsoft.com">mailto:rsparks@dynamicsoft.com</A=
>]</FONT>=20
  <BR><FONT size=3D2>&gt; Sent: Tuesday, January 09, 2001 2:24 PM</FONT> =
<BR><FONT=20
  size=3D2>&gt; To: 'Rohan Mahy'; Sean Olson; Robert Sparks</FONT> =
<BR><FONT=20
  size=3D2>&gt; Cc: sip</FONT> <BR><FONT size=3D2>&gt; Subject: RE: =
[SIP] REFER=20
  progress</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =

  </FONT><BR><FONT size=3D2>&gt; As far as I can thell, You and Sean are =
assuming=20
  you get</FONT> <BR><FONT size=3D2>&gt; exactly one NOTIFY then. =
</FONT><BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; At that point we're just =
quibbling on=20
  the method name.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; Or=20
  do you disagree? If you are assuming more than one</FONT> <BR><FONT=20
  size=3D2>&gt; NOTIFY, then I think you missed my point.</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; RjS</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  From: Rohan Mahy [<A=20
  href=3D"mailto:rohan@cisco.com">mailto:rohan@cisco.com</A>]</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; Sent: Tuesday, January 09, 2001 12:50 PM</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; To: Sean Olson; Robert Sparks</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; Cc: sip@lists.bell-labs.com</FONT> <BR><FONT size=3D2>&gt; &gt; =
Subject:=20
  Re: [SIP] REFER progress</FONT> <BR><FONT size=3D2>&gt; &gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; Hi,</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; I agree with =
Sean that an=20
  implicit NOTIFY is </FONT><BR><FONT size=3D2>&gt; straightforward, no=20
  more</FONT> <BR><FONT size=3D2>&gt; &gt; complicated than REFERDONE =
and solves=20
  the timeout problem.&nbsp; I </FONT><BR><FONT size=3D2>&gt; &gt; hope =
we=20
  don't</FONT> <BR><FONT size=3D2>&gt; &gt; need a meeting to close this =

  issue.&nbsp; ;-)</FONT> <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT=20
  size=3D2>&gt; &gt; The "other" problem, however, is the one that =
opened the=20
  </FONT><BR><FONT size=3D2>&gt; can of worms.</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  What primitive(s) do you use to get attended transfer to =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; work?&nbsp; All of the</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  proposals (something like 4 of them) work and solve the =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; requirement for an</FONT> <BR><FONT size=3D2>&gt; =
&gt; attended=20
  transfer.&nbsp; Some of these proposals deal more with =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; the&nbsp; bis draft</FONT> <BR><FONT size=3D2>&gt; =
&gt; (see=20
  Tom Taylor's post today).&nbsp; Everyone seems to want other =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; features as</FONT> <BR><FONT size=3D2>&gt; &gt; =
well, but we=20
  need to see at least a "sketch" of the </FONT><BR><FONT size=3D2>&gt; =
complete=20
  features</FONT> <BR><FONT size=3D2>&gt; &gt; picture associated with =
each=20
  proposal.&nbsp; This is why I </FONT><BR><FONT size=3D2>&gt; &gt; =
proposed the=20
  one-day</FONT> <BR><FONT size=3D2>&gt; &gt; face-to-face =
meeting.</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; =
thanks,</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; -rohan</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
  </FONT><BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; =
&gt;=20
  </FONT><BR><FONT size=3D2>&gt; &gt; At 12:15 PM 1/9/01 , Sean Olson=20
  wrote:</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;I'm sorry, I don't see =
the=20
  standardization of the</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;REFERDONE as=20
  being any easier than the standardization</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  &gt;of a NOTIFY to serve the same purpose.</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;To satisfy a need stated =
by Billy,=20
  the</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;body of the NOTIFY could =
simply be=20
  the SDP</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;from the 200 OK =
(assuming an=20
  INVITE) or empty</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;for a BYE. =
Uses of=20
  REFER for other methods would</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;need to be=20
  specified in extension drafts.</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;The=20
  Event: token could be "referdone".</FONT> <BR><FONT size=3D2>&gt; &gt; =

  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;Is there anything else =
that needs=20
  to be specified</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;for the use of =
NOTIFY=20
  that I am missing?</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt;I don't wish to drag this out forever. I =
think</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt;the solution is fairly simple and=20
  straightforward</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;and could be =
extended in=20
  the future.</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; &gt;Please point out faults with this proposal =
and</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt;areas of implementation =
difficulty.</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt;/sean</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
  &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;Robert Sparks =
wrote:</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;=20
  a.s. This got a little long - sorry</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
  &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It does contain a concrete=20
  proposal.</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; =
------------</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt;&gt; I think we are falling into a =
set of=20
  traps</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; with the REFER =
discussions,=20
  endangering an</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; already =
overdue=20
  deliverable.</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt;&gt; The worst is specification creep. The =
group</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt;&gt; was pretty happy with the =
functionality=20
  of</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; the current draft. =
When we=20
  tripped up on the</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; timeout =
problem,=20
  we saw a host of extra </FONT><BR><FONT size=3D2>&gt; &gt; &gt;&gt;=20
  functionality we could add while working</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  &gt;&gt; around that problem.</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt;&gt; Most of us have =
gravitated towards=20
  a model</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; where REFER is =
answered=20
  with a set of</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; reciprocal =
responses=20
  (essentially NOTIFYs,</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; =
possibly of a=20
  different name, with or without</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt; an=20
  explicit subscribe). What we _haven't_</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
  &gt;&gt; spent much time on is the profile of those</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; &gt;&gt; responses. How many can there be? What =
do</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt;&gt; they contain?</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt;&gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt;&gt; I really =
anticipate=20
  the answers to those last</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; =
questions=20
  will vary widely depending on the</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;=20
  application using REFER. We want to be able</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  &gt;&gt; to do other things than transfer (this is </FONT><BR><FONT=20
  size=3D2>&gt; &gt; &gt;&gt; why the method got renamed from =
TRANSFER).</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt;&gt; A rich response set for a REFER =
that=20
  triggers</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; a SUBSCRIBE is =
likely to=20
  be entirely different</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; in =
character=20
  from one that triggers an INVITE.</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt;&gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt;&gt; PROPOSAL</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; In =
interests of=20
  meeting our working group</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; =

  deliverable on this topic (now _WAY_ overdue),</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; &gt;&gt; I suggest that obtaining this rich response</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt;&gt; set has shown itself to be too big a bite. =
I</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt;&gt; propose that it is time to fall =
back to a=20
  single</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; REFERDONE =
reciprocal=20
  request, carrying the</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; =
information=20
  that is provided in the current</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;=20
  draft's final response. This would provide a</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  &gt;&gt; baseline version of REFER that would meet the</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt;&gt; requirements the current draft =
addresses.</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; &gt;&gt; </FONT><BR><FONT size=3D2>&gt; =
&gt; &gt;&gt;=20
  I further propose that when we complete that work,</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; &gt;&gt; we can return to REFER and define an =
extension=20
  that</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; would get the richer =
response=20
  set, addressing the</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;&gt; =
current lack of=20
  definition of that response set</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;=20
  with something like sip-event profiles.</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
  &gt;&gt; </FONT><BR><FONT size=3D2>&gt; &gt; &gt;&gt; RjS</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt;&gt; </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt;&gt;=20
  </FONT><BR><FONT size=3D2>&gt; &gt; &gt;&gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  &gt;&gt; _______________________________________________</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; &gt;&gt; SIP mailing list</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  &gt;&gt; SIP@lists.bell-labs.com</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;&gt; <A=20
  href=3D"http://lists.bell-labs.com/mailman/listinfo/sip"=20
  =
target=3D_blank>http://lists.bell-labs.com/mailman/listinfo/sip</A></FONT=
>=20
  <BR><FONT size=3D2>&gt; &gt; &gt;</FONT> <BR><FONT size=3D2>&gt; &gt; =
&gt;</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;=20
  &gt;_______________________________________________</FONT> <BR><FONT=20
  size=3D2>&gt; &gt; &gt;SIP mailing list</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
  &gt;SIP@lists.bell-labs.com</FONT> <BR><FONT size=3D2>&gt; &gt; &gt;<A =

  href=3D"http://lists.bell-labs.com/mailman/listinfo/sip"=20
  =
target=3D_blank>http://lists.bell-labs.com/mailman/listinfo/sip</A></FONT=
>=20
  <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
  _______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
  SIP mailing list</FONT> <BR><FONT size=3D2>&gt; =
SIP@lists.bell-labs.com</FONT>=20
  <BR><FONT size=3D2>&gt; <A=20
  href=3D"http://lists.bell-labs.com/mailman/listinfo/sip"=20
  =
target=3D_blank>http://lists.bell-labs.com/mailman/listinfo/sip</A></FONT=
>=20
  <BR><FONT size=3D2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0000_01C07A55.A1123DF0--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 18:00:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22666
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 18:00:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id ACB9C44338; Tue,  9 Jan 2001 17:01:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id D801D44337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 17:00:38 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f09Mqr015861;
	Tue, 9 Jan 2001 16:52:53 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: Robert Sparks <rsparks@dynamicsoft.com>
Cc: "'Tom-PT Taylor'" <taylor@nortelnetworks.com>,
        "'Rohan Mahy'" <rohan@cisco.com>, Sean Olson <sean.olson@ericsson.com>,
        sip <sip@lists.bell-labs.com>
Subject: Re: [SIP] REFER progress
Message-ID: <20010109165252.A19994@fdd.com>
References: <28560036253BD41191A10000F8BCBD11034BD1A4@zcard00g.ca.nortel.com> <9BF66EBF6BEFD942915B4D4D45C051F30474B1@DYN-TX-EXCH-001.dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F30474B1@DYN-TX-EXCH-001.dynamicsoft.com>; from rsparks@dynamicsoft.com on Tue, Jan 09, 2001 at 04:02:51PM -0600
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 16:52:52 -0600


I beg we use NOTIFY or REFERDONE if the call-leg has
not had an INVITE, and if it has, send INVITE or BYE.
Otherwise the REFER sender may have to
generate and send ringback when a blind transfer
fails.  The REFER may take some time before
it fails, so he would need to alert his user who
thought the call was gone.

--
Rick
rick_dean@3com.com

On Tue, Jan 09, 2001 at 04:02:51PM -0600, Robert Sparks wrote:
> If you have enough of the SUB/NOTIFY mechanism to include an event
> header, you can create profiles on the event that will tell you what
> the many NOTIFYs coming back mean. I again argue that to go down
> this path sanely, you want an explicit subscribe to a particular event.
> 
> Now - to push again for closure of the work item at hand.
> 
> Allowing more than one NOTIFY is probably solvable, but is
> going to take a _lot_ of discussion. If we restrict the behavior
> to one reciprocal request, and call it NOTIFY, we close
> the door on allowing more than one NOTIFY in the future.
> 
> Hence I push again for REFERDONE. That gets us to where we
> thought we were with NOTIFY before we ran afoul of the timeout
> problem. This will satisfy the working group deliverable.
> 
> _Future_ work can work add notifies to the scenario by extension,
> preferably in the context of SIP Events.
> 
> 
> RjS
> 
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Tuesday, January 09, 2001 2:54 PM
> To: Robert Sparks; 'Rohan Mahy'; Sean Olson
> Cc: sip
> Subject: RE: [SIP] REFER progress
> 
> 
> 
> I assumed the originator would be subscribed to all of the responses
> associated with the transaction, simply as a consequence of piggybacking on
> the general SUBS/NOTIFY mechanism as applied to SIP events.
> 
> > -----Original Message-----
> > From: Robert Sparks [ mailto:rsparks@dynamicsoft.com]
> > Sent: Tuesday, January 09, 2001 2:24 PM
> > To: 'Rohan Mahy'; Sean Olson; Robert Sparks
> > Cc: sip
> > Subject: RE: [SIP] REFER progress
> >
> >
> > As far as I can thell, You and Sean are assuming you get
> > exactly one NOTIFY then.
> >
> > At that point we're just quibbling on the method name.
> >
> > Or do you disagree? If you are assuming more than one
> > NOTIFY, then I think you missed my point.
> >
> > RjS
> >
> >
> >
> > > -----Original Message-----
> > > From: Rohan Mahy [ mailto:rohan@cisco.com]
> > > Sent: Tuesday, January 09, 2001 12:50 PM
> > > To: Sean Olson; Robert Sparks
> > > Cc: sip@lists.bell-labs.com
> > > Subject: Re: [SIP] REFER progress
> > >
> > >
> > > Hi,
> > >
> > > I agree with Sean that an implicit NOTIFY is
> > straightforward, no more
> > > complicated than REFERDONE and solves the timeout problem.  I
> > > hope we don't
> > > need a meeting to close this issue.  ;-)
> > >
> > > The "other" problem, however, is the one that opened the
> > can of worms.
> > > What primitive(s) do you use to get attended transfer to
> > > work?  All of the
> > > proposals (something like 4 of them) work and solve the
> > > requirement for an
> > > attended transfer.  Some of these proposals deal more with
> > > the  bis draft
> > > (see Tom Taylor's post today).  Everyone seems to want other
> > > features as
> > > well, but we need to see at least a "sketch" of the
> > complete features
> > > picture associated with each proposal.  This is why I
> > > proposed the one-day
> > > face-to-face meeting.
> > >
> > > thanks,
> > > -rohan
> > >
> > >
> > >
> > > At 12:15 PM 1/9/01 , Sean Olson wrote:
> > > >I'm sorry, I don't see the standardization of the
> > > >REFERDONE as being any easier than the standardization
> > > >of a NOTIFY to serve the same purpose.
> > > >
> > > >To satisfy a need stated by Billy, the
> > > >body of the NOTIFY could simply be the SDP
> > > >from the 200 OK (assuming an INVITE) or empty
> > > >for a BYE. Uses of REFER for other methods would
> > > >need to be specified in extension drafts.
> > > >The Event: token could be "referdone".
> > > >
> > > >Is there anything else that needs to be specified
> > > >for the use of NOTIFY that I am missing?
> > > >
> > > >I don't wish to drag this out forever. I think
> > > >the solution is fairly simple and straightforward
> > > >and could be extended in the future.
> > > >
> > > >Please point out faults with this proposal and
> > > >areas of implementation difficulty.
> > > >/sean
> > > >
> > > >Robert Sparks wrote:
> > > >
> > > >> a.s. This got a little long - sorry
> > > >>      It does contain a concrete proposal.
> > > >> ------------
> > > >> I think we are falling into a set of traps
> > > >> with the REFER discussions, endangering an
> > > >> already overdue deliverable.
> > > >>
> > > >> The worst is specification creep. The group
> > > >> was pretty happy with the functionality of
> > > >> the current draft. When we tripped up on the
> > > >> timeout problem, we saw a host of extra
> > > >> functionality we could add while working
> > > >> around that problem.
> > > >>
> > > >> Most of us have gravitated towards a model
> > > >> where REFER is answered with a set of
> > > >> reciprocal responses (essentially NOTIFYs,
> > > >> possibly of a different name, with or without
> > > >> an explicit subscribe). What we _haven't_
> > > >> spent much time on is the profile of those
> > > >> responses. How many can there be? What do
> > > >> they contain?
> > > >>
> > > >> I really anticipate the answers to those last
> > > >> questions will vary widely depending on the
> > > >> application using REFER. We want to be able
> > > >> to do other things than transfer (this is
> > > >> why the method got renamed from TRANSFER).
> > > >> A rich response set for a REFER that triggers
> > > >> a SUBSCRIBE is likely to be entirely different
> > > >> in character from one that triggers an INVITE.
> > > >>
> > > >>
> > > >> PROPOSAL
> > > >> In interests of meeting our working group
> > > >> deliverable on this topic (now _WAY_ overdue),
> > > >> I suggest that obtaining this rich response
> > > >> set has shown itself to be too big a bite. I
> > > >> propose that it is time to fall back to a single
> > > >> REFERDONE reciprocal request, carrying the
> > > >> information that is provided in the current
> > > >> draft's final response. This would provide a
> > > >> baseline version of REFER that would meet the
> > > >> requirements the current draft addresses.
> > > >>
> > > >> I further propose that when we complete that work,
> > > >> we can return to REFER and define an extension that
> > > >> would get the richer response set, addressing the
> > > >> current lack of definition of that response set
> > > >> with something like sip-event profiles.
> > > >>
> > > >> RjS
> > > >>
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> SIP mailing list
> > > >> SIP@lists.bell-labs.com
> > > >> http://lists.bell-labs.com/mailman/listinfo/sip
> > > >
> > > >
> > > >_______________________________________________
> > > >SIP mailing list
> > > >SIP@lists.bell-labs.com
> > > > http://lists.bell-labs.com/mailman/listinfo/sip
> > >
> >
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> >
> 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 18:04:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22770
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 18:04:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7D1CF44352; Tue,  9 Jan 2001 17:05:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 5E8794434E
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 17:04:01 -0500 (EST)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <CKD5PWSX>; Tue, 9 Jan 2001 15:03:57 -0800
Message-ID: <E79883AEA37FD411A58C00508BAC5F4B2B5C31@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Robert Sparks'" <rsparks@dynamicsoft.com>,
        "'Tom-PT Taylor'" <taylor@nortelnetworks.com>,
        "'Rohan Mahy'" <rohan@cisco.com>, Sean Olson <sean.olson@ericsson.com>
Cc: sip <sip@lists.bell-labs.com>
Subject: RE: [SIP] REFER progress
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C07A90.71E4E740"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 15:03:57 -0800

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_01C07A90.71E4E740
Content-Type: text/plain;
	charset="iso-8859-1"

This makes some sense to me. If the alternate proposal is saying that UA's
"don't really need to implement the full SUB/NOT for REFER (eg using
implicit subscription, single response)" then it is not really SUB/NOT at
all - so why confuse things and call it that? As Robert Sparks says, if you
want to add full(er) subscription functionality later then it simply
confuses things between UA's that do and do not fully implement
SUBSCRIBE/NOTIFY.
 
If REFERDONE is being used _explicitly_ for REFER response status then this
seems more in line with our design goals than _implicitly_ using a NOTIFY to
do the same thing (and easier to parse IMO). I am not advocating that each
function gets its own method but if you are saying that UA's do not need to
implement full SUB/NOT then we should not be using NOTIFY for this purpose.
 
Robert.

-- My opinions are my own and should not be taken as representing those of
Nuera Communications, Inc. -- 

 
 -----Original Message-----
From: Robert Sparks [ mailto:rsparks@dynamicsoft.com
<mailto:rsparks@dynamicsoft.com> ]
Sent: Wednesday, January 10, 2001 9:03 AM
To: 'Tom-PT Taylor'; Robert Sparks; 'Rohan Mahy'; Sean Olson
Cc: sip
Subject: RE: [SIP] REFER progress



If you have enough of the SUB/NOTIFY mechanism to include an event
header, you can create profiles on the event that will tell you what
the many NOTIFYs coming back mean. I again argue that to go down
this path sanely, you want an explicit subscribe to a particular event.
 
Now - to push again for closure of the work item at hand.
 
Allowing more than one NOTIFY is probably solvable, but is
going to take a _lot_ of discussion. If we restrict the behavior
to one reciprocal request, and call it NOTIFY, we close
the door on allowing more than one NOTIFY in the future.
 
Hence I push again for REFERDONE. That gets us to where we
thought we were with NOTIFY before we ran afoul of the timeout
problem. This will satisfy the working group deliverable.
 
_Future_ work can work add notifies to the scenario by extension,
preferably in the context of SIP Events.
 
 
RjS

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, January 09, 2001 2:54 PM
To: Robert Sparks; 'Rohan Mahy'; Sean Olson
Cc: sip
Subject: RE: [SIP] REFER progress



I assumed the originator would be subscribed to all of the responses
associated with the transaction, simply as a consequence of piggybacking on
the general SUBS/NOTIFY mechanism as applied to SIP events.

> -----Original Message----- 
> From: Robert Sparks [ mailto:rsparks@dynamicsoft.com
<mailto:rsparks@dynamicsoft.com> ] 
> Sent: Tuesday, January 09, 2001 2:24 PM 
> To: 'Rohan Mahy'; Sean Olson; Robert Sparks 
> Cc: sip 
> Subject: RE: [SIP] REFER progress 
> 
> 
> As far as I can thell, You and Sean are assuming you get 
> exactly one NOTIFY then. 
> 
> At that point we're just quibbling on the method name. 
> 
> Or do you disagree? If you are assuming more than one 
> NOTIFY, then I think you missed my point. 
> 
> RjS 
> 
> 
> 
> > -----Original Message----- 
> > From: Rohan Mahy [ mailto:rohan@cisco.com <mailto:rohan@cisco.com> ] 
> > Sent: Tuesday, January 09, 2001 12:50 PM 
> > To: Sean Olson; Robert Sparks 
> > Cc: sip@lists.bell-labs.com 
> > Subject: Re: [SIP] REFER progress 
> > 
> > 
> > Hi, 
> > 
> > I agree with Sean that an implicit NOTIFY is 
> straightforward, no more 
> > complicated than REFERDONE and solves the timeout problem.  I 
> > hope we don't 
> > need a meeting to close this issue.  ;-) 
> > 
> > The "other" problem, however, is the one that opened the 
> can of worms. 
> > What primitive(s) do you use to get attended transfer to 
> > work?  All of the 
> > proposals (something like 4 of them) work and solve the 
> > requirement for an 
> > attended transfer.  Some of these proposals deal more with 
> > the  bis draft 
> > (see Tom Taylor's post today).  Everyone seems to want other 
> > features as 
> > well, but we need to see at least a "sketch" of the 
> complete features 
> > picture associated with each proposal.  This is why I 
> > proposed the one-day 
> > face-to-face meeting. 
> > 
> > thanks, 
> > -rohan 
> > 
> > 
> > 
> > At 12:15 PM 1/9/01 , Sean Olson wrote: 
> > >I'm sorry, I don't see the standardization of the 
> > >REFERDONE as being any easier than the standardization 
> > >of a NOTIFY to serve the same purpose. 
> > > 
> > >To satisfy a need stated by Billy, the 
> > >body of the NOTIFY could simply be the SDP 
> > >from the 200 OK (assuming an INVITE) or empty 
> > >for a BYE. Uses of REFER for other methods would 
> > >need to be specified in extension drafts. 
> > >The Event: token could be "referdone". 
> > > 
> > >Is there anything else that needs to be specified 
> > >for the use of NOTIFY that I am missing? 
> > > 
> > >I don't wish to drag this out forever. I think 
> > >the solution is fairly simple and straightforward 
> > >and could be extended in the future. 
> > > 
> > >Please point out faults with this proposal and 
> > >areas of implementation difficulty. 
> > >/sean 
> > > 
> > >Robert Sparks wrote: 
> > > 
> > >> a.s. This got a little long - sorry 
> > >>      It does contain a concrete proposal. 
> > >> ------------ 
> > >> I think we are falling into a set of traps 
> > >> with the REFER discussions, endangering an 
> > >> already overdue deliverable. 
> > >> 
> > >> The worst is specification creep. The group 
> > >> was pretty happy with the functionality of 
> > >> the current draft. When we tripped up on the 
> > >> timeout problem, we saw a host of extra 
> > >> functionality we could add while working 
> > >> around that problem. 
> > >> 
> > >> Most of us have gravitated towards a model 
> > >> where REFER is answered with a set of 
> > >> reciprocal responses (essentially NOTIFYs, 
> > >> possibly of a different name, with or without 
> > >> an explicit subscribe). What we _haven't_ 
> > >> spent much time on is the profile of those 
> > >> responses. How many can there be? What do 
> > >> they contain? 
> > >> 
> > >> I really anticipate the answers to those last 
> > >> questions will vary widely depending on the 
> > >> application using REFER. We want to be able 
> > >> to do other things than transfer (this is 
> > >> why the method got renamed from TRANSFER). 
> > >> A rich response set for a REFER that triggers 
> > >> a SUBSCRIBE is likely to be entirely different 
> > >> in character from one that triggers an INVITE. 
> > >> 
> > >> 
> > >> PROPOSAL 
> > >> In interests of meeting our working group 
> > >> deliverable on this topic (now _WAY_ overdue), 
> > >> I suggest that obtaining this rich response 
> > >> set has shown itself to be too big a bite. I 
> > >> propose that it is time to fall back to a single 
> > >> REFERDONE reciprocal request, carrying the 
> > >> information that is provided in the current 
> > >> draft's final response. This would provide a 
> > >> baseline version of REFER that would meet the 
> > >> requirements the current draft addresses. 
> > >> 
> > >> I further propose that when we complete that work, 
> > >> we can return to REFER and define an extension that 
> > >> would get the richer response set, addressing the 
> > >> current lack of definition of that response set 
> > >> with something like sip-event profiles. 
> > >> 
> > >> RjS 
> > >> 
> > >> 
> > >> 
> > >> _______________________________________________ 
> > >> SIP mailing list 
> > >> SIP@lists.bell-labs.com 
> > >> http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>  
> > > 
> > > 
> > >_______________________________________________ 
> > >SIP mailing list 
> > >SIP@lists.bell-labs.com 
> > > http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>  
> > 
> 
> 
> _______________________________________________ 
> SIP mailing list 
> SIP@lists.bell-labs.com 
> http://lists.bell-labs.com/mailman/listinfo/sip
<http://lists.bell-labs.com/mailman/listinfo/sip>  
> 


------_=_NextPart_001_01C07A90.71E4E740
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<TITLE>RE: [SIP] REFER progress</TITLE>
<META content='"MSHTML 4.72.3110.7"' name=GENERATOR>
</HEAD>
<BODY>
<DIV><SPAN class=720285422-08012001><FONT color=#0000ff face=Verdana size=2>This 
makes some sense to me. If the alternate proposal is saying that UA's 
&quot;don't really need to implement the full SUB/NOT for REFER (eg using 
implicit subscription, single response)&quot; then it is not really SUB/NOT at 
all - so why confuse things and call it that? As Robert Sparks says, if you want 
to add full(er) subscription functionality later then it simply confuses things 
between UA's that do and do not fully implement 
SUBSCRIBE/NOTIFY.</FONT></SPAN></DIV>
<DIV><SPAN class=720285422-08012001><FONT color=#0000ff face=Verdana 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=720285422-08012001><FONT color=#0000ff face=Verdana size=2>If 
REFERDONE is being used _explicitly_ for REFER response status then this seems 
more in line with our design goals than _implicitly_ using a NOTIFY to do the 
same thing (and easier to parse IMO). I am not advocating that each function 
gets its own method but if you are saying that UA's do not need to implement 
full SUB/NOT then we should not be using NOTIFY for this 
purpose.</FONT></SPAN></DIV>
<DIV><SPAN class=720285422-08012001><FONT color=#0000ff face=Verdana 
size=2></FONT></SPAN><FONT face="Times New Roman" size=2><SPAN 
class=720285422-08012001><FONT color=#0000ff face=Verdana 
size=2></FONT></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Times New Roman" size=2><SPAN class=720285422-08012001><FONT 
color=#0000ff face=Verdana size=2></FONT></SPAN></FONT><SPAN 
class=720285422-08012001><FONT color=#0000ff face=Verdana 
size=2>Robert.</FONT></SPAN></DIV>
<DIV>
<P><FONT face="Courier New" size=2><FONT color=#0000ff>-- My opinions are my own 
and should not be taken as representing those of Nuera Communications, Inc. -- 
</FONT></FONT><FONT color=#0000ff></FONT></P></DIV>
<DIV><FONT face="Times New Roman" size=2><SPAN class=720285422-08012001><FONT 
color=#0000ff face=Verdana size=2>&nbsp;</FONT></SPAN></FONT></DIV>
<DIV><FONT face="Times New Roman" size=2><SPAN class=720285422-08012001><FONT 
color=#0000ff face=Verdana size=2>&nbsp;</FONT></SPAN>-----Original 
Message-----<BR><B>From:</B> Robert Sparks [<A 
href="mailto:rsparks@dynamicsoft.com">mailto:rsparks@dynamicsoft.com</A>]<BR><B>Sent:</B> 
Wednesday, January 10, 2001 9:03 AM<BR><B>To:</B> 'Tom-PT Taylor'; Robert 
Sparks; 'Rohan Mahy'; Sean Olson<BR><B>Cc:</B> sip<BR><B>Subject:</B> RE: [SIP] 
REFER progress<BR><BR></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=047275221-09012001>If 
    you have enough of the SUB/NOTIFY mechanism to include an 
    event</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001>header, you can create profiles on the event that 
    will tell you what</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001>the many NOTIFYs coming back mean. I again argue 
    that to go down</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001>this path sanely, you want an explicit subscribe to 
    a particular event.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001>Now - to push again for closure of the work item at 
    hand.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001>Allowing more than one NOTIFY is probably solvable, 
    but is</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001>going to take a _lot_ of discussion. If we restrict 
    the behavior</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=047275221-09012001>to 
    one reciprocal request, and call it NOTIFY, we close</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001>the door on allowing more than one NOTIFY in the 
    future.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001>Hence I push again for REFERDONE. That gets us to 
    where we</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001>thought we were with NOTIFY before we ran afoul of 
    the timeout</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001>problem. This will satisfy the working group 
    deliverable.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001>_Future_ work can work add notifies to the scenario 
    by extension,</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001>preferably in the </SPAN></FONT><FONT color=#0000ff 
    face=Arial size=2><SPAN class=047275221-09012001>context of SIP 
    Events.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=047275221-09012001>RjS</SPAN></FONT></DIV>
    <BLOCKQUOTE 
    style="BORDER-LEFT: #0000ff solid 2px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
        <DIV align=left class=OutlookMessageHeader dir = ltr><FONT face=Tahoma 
        size=2>-----Original Message-----<BR><B>From:</B> Tom-PT Taylor 
        [mailto:taylor@nortelnetworks.com]<BR><B>Sent:</B> Tuesday, January 09, 
        2001 2:54 PM<BR><B>To:</B> Robert Sparks; 'Rohan Mahy'; Sean 
        Olson<BR><B>Cc:</B> sip<BR><B>Subject:</B> RE: [SIP] REFER 
        progress<BR><BR></DIV></FONT>
        <P><FONT size=2>I assumed the originator would be subscribed to all of 
        the responses associated with the transaction, simply as a consequence 
        of piggybacking on the general SUBS/NOTIFY mechanism as applied to SIP 
        events.</FONT></P>
        <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT 
        size=2>&gt; From: Robert Sparks [<A 
        href="mailto:rsparks@dynamicsoft.com">mailto:rsparks@dynamicsoft.com</A>]</FONT> 
        <BR><FONT size=2>&gt; Sent: Tuesday, January 09, 2001 2:24 PM</FONT> 
        <BR><FONT size=2>&gt; To: 'Rohan Mahy'; Sean Olson; Robert Sparks</FONT> 
        <BR><FONT size=2>&gt; Cc: sip</FONT> <BR><FONT size=2>&gt; Subject: RE: 
        [SIP] REFER progress</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
        size=2>&gt; </FONT><BR><FONT size=2>&gt; As far as I can thell, You and 
        Sean are assuming you get</FONT> <BR><FONT size=2>&gt; exactly one 
        NOTIFY then. </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
        At that point we're just quibbling on the method name.</FONT> <BR><FONT 
        size=2>&gt; </FONT><BR><FONT size=2>&gt; Or do you disagree? If you are 
        assuming more than one</FONT> <BR><FONT size=2>&gt; NOTIFY, then I think 
        you missed my point.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
        size=2>&gt; RjS</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
        size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
        &gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt; From: 
        Rohan Mahy [<A 
        href="mailto:rohan@cisco.com">mailto:rohan@cisco.com</A>]</FONT> 
        <BR><FONT size=2>&gt; &gt; Sent: Tuesday, January 09, 2001 12:50 
        PM</FONT> <BR><FONT size=2>&gt; &gt; To: Sean Olson; Robert 
        Sparks</FONT> <BR><FONT size=2>&gt; &gt; Cc: 
        sip@lists.bell-labs.com</FONT> <BR><FONT size=2>&gt; &gt; Subject: Re: 
        [SIP] REFER progress</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
        size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Hi,</FONT> <BR><FONT 
        size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; I agree with Sean 
        that an implicit NOTIFY is </FONT><BR><FONT size=2>&gt; straightforward, 
        no more</FONT> <BR><FONT size=2>&gt; &gt; complicated than REFERDONE and 
        solves the timeout problem.&nbsp; I </FONT><BR><FONT size=2>&gt; &gt; 
        hope we don't</FONT> <BR><FONT size=2>&gt; &gt; need a meeting to close 
        this issue.&nbsp; ;-)</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
        size=2>&gt; &gt; The &quot;other&quot; problem, however, is the one that 
        opened the </FONT><BR><FONT size=2>&gt; can of worms.</FONT> <BR><FONT 
        size=2>&gt; &gt; What primitive(s) do you use to get attended transfer 
        to </FONT><BR><FONT size=2>&gt; &gt; work?&nbsp; All of the</FONT> 
        <BR><FONT size=2>&gt; &gt; proposals (something like 4 of them) work and 
        solve the </FONT><BR><FONT size=2>&gt; &gt; requirement for an</FONT> 
        <BR><FONT size=2>&gt; &gt; attended transfer.&nbsp; Some of these 
        proposals deal more with </FONT><BR><FONT size=2>&gt; &gt; the&nbsp; bis 
        draft</FONT> <BR><FONT size=2>&gt; &gt; (see Tom Taylor's post 
        today).&nbsp; Everyone seems to want other </FONT><BR><FONT size=2>&gt; 
        &gt; features as</FONT> <BR><FONT size=2>&gt; &gt; well, but we need to 
        see at least a &quot;sketch&quot; of the </FONT><BR><FONT size=2>&gt; 
        complete features</FONT> <BR><FONT size=2>&gt; &gt; picture associated 
        with each proposal.&nbsp; This is why I </FONT><BR><FONT size=2>&gt; 
        &gt; proposed the one-day</FONT> <BR><FONT size=2>&gt; &gt; face-to-face 
        meeting.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
        &gt; thanks,</FONT> <BR><FONT size=2>&gt; &gt; -rohan</FONT> <BR><FONT 
        size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
        size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; At 12:15 PM 1/9/01 , 
        Sean Olson wrote:</FONT> <BR><FONT size=2>&gt; &gt; &gt;I'm sorry, I 
        don't see the standardization of the</FONT> <BR><FONT size=2>&gt; &gt; 
        &gt;REFERDONE as being any easier than the standardization</FONT> 
        <BR><FONT size=2>&gt; &gt; &gt;of a NOTIFY to serve the same 
        purpose.</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT 
        size=2>&gt; &gt; &gt;To satisfy a need stated by Billy, the</FONT> 
        <BR><FONT size=2>&gt; &gt; &gt;body of the NOTIFY could simply be the 
        SDP</FONT> <BR><FONT size=2>&gt; &gt; &gt;from the 200 OK (assuming an 
        INVITE) or empty</FONT> <BR><FONT size=2>&gt; &gt; &gt;for a BYE. Uses 
        of REFER for other methods would</FONT> <BR><FONT size=2>&gt; &gt; 
        &gt;need to be specified in extension drafts.</FONT> <BR><FONT 
        size=2>&gt; &gt; &gt;The Event: token could be 
        &quot;referdone&quot;.</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> 
        <BR><FONT size=2>&gt; &gt; &gt;Is there anything else that needs to be 
        specified</FONT> <BR><FONT size=2>&gt; &gt; &gt;for the use of NOTIFY 
        that I am missing?</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> 
        <BR><FONT size=2>&gt; &gt; &gt;I don't wish to drag this out forever. I 
        think</FONT> <BR><FONT size=2>&gt; &gt; &gt;the solution is fairly 
        simple and straightforward</FONT> <BR><FONT size=2>&gt; &gt; &gt;and 
        could be extended in the future.</FONT> <BR><FONT size=2>&gt; &gt; 
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;Please point out faults with 
        this proposal and</FONT> <BR><FONT size=2>&gt; &gt; &gt;areas of 
        implementation difficulty.</FONT> <BR><FONT size=2>&gt; &gt; 
        &gt;/sean</FONT> <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT 
        size=2>&gt; &gt; &gt;Robert Sparks wrote:</FONT> <BR><FONT size=2>&gt; 
        &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; a.s. This got a 
        little long - sorry</FONT> <BR><FONT size=2>&gt; &gt; 
        &gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It does contain a concrete 
        proposal.</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; ------------</FONT> 
        <BR><FONT size=2>&gt; &gt; &gt;&gt; I think we are falling into a set of 
        traps</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; with the REFER 
        discussions, endangering an</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; 
        already overdue deliverable.</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; 
        </FONT><BR><FONT size=2>&gt; &gt; &gt;&gt; The worst is specification 
        creep. The group</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; was pretty 
        happy with the functionality of</FONT> <BR><FONT size=2>&gt; &gt; 
        &gt;&gt; the current draft. When we tripped up on the</FONT> <BR><FONT 
        size=2>&gt; &gt; &gt;&gt; timeout problem, we saw a host of extra 
        </FONT><BR><FONT size=2>&gt; &gt; &gt;&gt; functionality we could add 
        while working</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; around that 
        problem.</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; </FONT><BR><FONT 
        size=2>&gt; &gt; &gt;&gt; Most of us have gravitated towards a 
        model</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; where REFER is answered 
        with a set of</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; reciprocal 
        responses (essentially NOTIFYs,</FONT> <BR><FONT size=2>&gt; &gt; 
        &gt;&gt; possibly of a different name, with or without</FONT> <BR><FONT 
        size=2>&gt; &gt; &gt;&gt; an explicit subscribe). What we 
        _haven't_</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; spent much time on 
        is the profile of those</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; 
        responses. How many can there be? What do</FONT> <BR><FONT size=2>&gt; 
        &gt; &gt;&gt; they contain?</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; 
        </FONT><BR><FONT size=2>&gt; &gt; &gt;&gt; I really anticipate the 
        answers to those last</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; 
        questions will vary widely depending on the</FONT> <BR><FONT size=2>&gt; 
        &gt; &gt;&gt; application using REFER. We want to be able</FONT> 
        <BR><FONT size=2>&gt; &gt; &gt;&gt; to do other things than transfer 
        (this is </FONT><BR><FONT size=2>&gt; &gt; &gt;&gt; why the method got 
        renamed from TRANSFER).</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; A 
        rich response set for a REFER that triggers</FONT> <BR><FONT size=2>&gt; 
        &gt; &gt;&gt; a SUBSCRIBE is likely to be entirely different</FONT> 
        <BR><FONT size=2>&gt; &gt; &gt;&gt; in character from one that triggers 
        an INVITE.</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; </FONT><BR><FONT 
        size=2>&gt; &gt; &gt;&gt; </FONT><BR><FONT size=2>&gt; &gt; &gt;&gt; 
        PROPOSAL</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; In interests of 
        meeting our working group</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; 
        deliverable on this topic (now _WAY_ overdue),</FONT> <BR><FONT 
        size=2>&gt; &gt; &gt;&gt; I suggest that obtaining this rich 
        response</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; set has shown itself 
        to be too big a bite. I</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; 
        propose that it is time to fall back to a single</FONT> <BR><FONT 
        size=2>&gt; &gt; &gt;&gt; REFERDONE reciprocal request, carrying 
        the</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; information that is 
        provided in the current</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; 
        draft's final response. This would provide a</FONT> <BR><FONT 
        size=2>&gt; &gt; &gt;&gt; baseline version of REFER that would meet 
        the</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; requirements the current 
        draft addresses.</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; 
        </FONT><BR><FONT size=2>&gt; &gt; &gt;&gt; I further propose that when 
        we complete that work,</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; we can 
        return to REFER and define an extension that</FONT> <BR><FONT 
        size=2>&gt; &gt; &gt;&gt; would get the richer response set, addressing 
        the</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; current lack of 
        definition of that response set</FONT> <BR><FONT size=2>&gt; &gt; 
        &gt;&gt; with something like sip-event profiles.</FONT> <BR><FONT 
        size=2>&gt; &gt; &gt;&gt; </FONT><BR><FONT size=2>&gt; &gt; &gt;&gt; 
        RjS</FONT> <BR><FONT size=2>&gt; &gt; &gt;&gt; </FONT><BR><FONT 
        size=2>&gt; &gt; &gt;&gt; </FONT><BR><FONT size=2>&gt; &gt; &gt;&gt; 
        </FONT><BR><FONT size=2>&gt; &gt; &gt;&gt; 
        _______________________________________________</FONT> <BR><FONT 
        size=2>&gt; &gt; &gt;&gt; SIP mailing list</FONT> <BR><FONT size=2>&gt; 
        &gt; &gt;&gt; SIP@lists.bell-labs.com</FONT> <BR><FONT size=2>&gt; &gt; 
        &gt;&gt; <A href="http://lists.bell-labs.com/mailman/listinfo/sip" 
        target=_blank>http://lists.bell-labs.com/mailman/listinfo/sip</A></FONT> 
        <BR><FONT size=2>&gt; &gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; 
        &gt;</FONT> <BR><FONT size=2>&gt; &gt; 
        &gt;_______________________________________________</FONT> <BR><FONT 
        size=2>&gt; &gt; &gt;SIP mailing list</FONT> <BR><FONT size=2>&gt; &gt; 
        &gt;SIP@lists.bell-labs.com</FONT> <BR><FONT size=2>&gt; &gt; &gt;<A 
        href="http://lists.bell-labs.com/mailman/listinfo/sip" 
        target=_blank>http://lists.bell-labs.com/mailman/listinfo/sip</A></FONT> 
        <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
        size=2>&gt; </FONT><BR><FONT size=2>&gt; 
        _______________________________________________</FONT> <BR><FONT 
        size=2>&gt; SIP mailing list</FONT> <BR><FONT size=2>&gt; 
        SIP@lists.bell-labs.com</FONT> <BR><FONT size=2>&gt; <A 
        href="http://lists.bell-labs.com/mailman/listinfo/sip" 
        target=_blank>http://lists.bell-labs.com/mailman/listinfo/sip</A></FONT> 
        <BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C07A90.71E4E740--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 18:34:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23222
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 18:34:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3AD7444339; Tue,  9 Jan 2001 17:35:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id C6E5A44337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 17:34:02 -0500 (EST)
Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f09NOqK14254;
	Tue, 9 Jan 2001 17:24:52 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f09NLT911582;
	Tue, 9 Jan 2001 17:21:29 -0600 (CST)
Received: from ericsson.com (pc050184.exu.ericsson.se [138.85.50.184]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA12650; Tue, 9 Jan 2001 17:24:51 -0600 (CST)
Message-ID: <3A5B9DC7.9090308@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
Cc: "'Robert Sparks'" <rsparks@dynamicsoft.com>,
        "'Tom-PT Taylor'" <taylor@nortelnetworks.com>,
        "'Rohan Mahy'" <rohan@cisco.com>, sip <sip@lists.bell-labs.com>
Subject: Re: [SIP] REFER progress
References: <E79883AEA37FD411A58C00508BAC5F4B2B5C31@exchange1.nuera.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 17:24:55 -0600
Content-Transfer-Encoding: 7bit

I have a small problem with this logic. What I am
proposing is perfectly inline with SUB/NOT and is
not a radical deviation from it. I argued for implicit
subscriptions in the SUB/NOT draft specifically for
this type of situation. With regards to the complexity
of the solution using NOTIFY, I don't see much difference
between NOTIFY and REFERDONE in this case. Both will
need to indicate a final response code. The NOTIFY
solution happens to use the Event: header. The body
of the NOTIFY may or may not contain SDP. The
receiving client of course is free to ignore it.
I'm not advocating anything like XML be used for this.
The only modification I would make in a future extension
would be the support of multiple NOTIFYs and this is
*very* easily handled by a client that supports a single
NOTIFY. (Provisional responses in the NOTIFY can simply
be ignored)

I'm not going to argue forever on this, I promise :)
I just would prefer that NOTIFY be used over REFERDONE
barring any more substantial arguments.

/sean

Fairlie-Cuninghame, Robert wrote:

> This makes some sense to me. If the alternate proposal is saying that 
> UA's "don't really need to implement the full SUB/NOT for REFER (eg 
> using implicit subscription, single response)" then it is not really 
> SUB/NOT at all - so why confuse things and call it that? As Robert 
> Sparks says, if you want to add full(er) subscription functionality 
> later then it simply confuses things between UA's that do and do not 
> fully implement SUBSCRIBE/NOTIFY.
> 
>  
> 
> If REFERDONE is being used _explicitly_ for REFER response status then 
> this seems more in line with our design goals than _implicitly_ using a 
> NOTIFY to do the same thing (and easier to parse IMO). I am not 
> advocating that each function gets its own method but if you are saying 
> that UA's do not need to implement full SUB/NOT then we should not be 
> using NOTIFY for this purpose.
> 
>  
> 
> Robert.
> 
> -- My opinions are my own and should not be taken as representing those 
> of Nuera Communications, Inc. --
> 
>  
> 
>  -----Original Message-----
> From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
> Sent: Wednesday, January 10, 2001 9:03 AM
> To: 'Tom-PT Taylor'; Robert Sparks; 'Rohan Mahy'; Sean Olson
> Cc: sip
> Subject: RE: [SIP] REFER progress
> 
>     If you have enough of the SUB/NOTIFY mechanism to include an event
>     
>     header, you can create profiles on the event that will tell you what
>     
>     the many NOTIFYs coming back mean. I again argue that to go down
>     
>     this path sanely, you want an explicit subscribe to a particular event.
>     
>      
>     
>     Now - to push again for closure of the work item at hand.
>     
>      
>     
>     Allowing more than one NOTIFY is probably solvable, but is
>     
>     going to take a _lot_ of discussion. If we restrict the behavior
>     
>     to one reciprocal request, and call it NOTIFY, we close
>     
>     the door on allowing more than one NOTIFY in the future.
>     
>      
>     
>     Hence I push again for REFERDONE. That gets us to where we
>     
>     thought we were with NOTIFY before we ran afoul of the timeout
>     
>     problem. This will satisfy the working group deliverable.
>     
>      
>     
>     _Future_ work can work add notifies to the scenario by extension,
>     
>     preferably in the context of SIP Events.
>     
>      
>     
>      
>     
>     RjS
>     
>         -----Original Message-----
>         From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>         Sent: Tuesday, January 09, 2001 2:54 PM
>         To: Robert Sparks; 'Rohan Mahy'; Sean Olson
>         Cc: sip
>         Subject: RE: [SIP] REFER progress
>         
>         I assumed the originator would be subscribed to all of the 
>         responses associated with the transaction, simply as a 
>         consequence of piggybacking on the general SUBS/NOTIFY mechanism 
>         as applied to SIP events.
>         
>          > -----Original Message-----
>          > From: Robert Sparks [mailto:rsparks@dynamicsoft.com]
>          > Sent: Tuesday, January 09, 2001 2:24 PM
>          > To: 'Rohan Mahy'; Sean Olson; Robert Sparks
>          > Cc: sip
>          > Subject: RE: [SIP] REFER progress
>          >
>          >
>          > As far as I can thell, You and Sean are assuming you get
>          > exactly one NOTIFY then.
>          >
>          > At that point we're just quibbling on the method name.
>          >
>          > Or do you disagree? If you are assuming more than one
>          > NOTIFY, then I think you missed my point.
>          >
>          > RjS
>          >
>          >
>          >
>          > > -----Original Message-----
>          > > From: Rohan Mahy [mailto:rohan@cisco.com]
>          > > Sent: Tuesday, January 09, 2001 12:50 PM
>          > > To: Sean Olson; Robert Sparks
>          > > Cc: sip@lists.bell-labs.com
>          > > Subject: Re: [SIP] REFER progress
>          > >
>          > >
>          > > Hi,
>          > >
>          > > I agree with Sean that an implicit NOTIFY is
>          > straightforward, no more
>          > > complicated than REFERDONE and solves the timeout problem.  I
>          > > hope we don't
>          > > need a meeting to close this issue.  ;-)
>          > >
>          > > The "other" problem, however, is the one that opened the
>          > can of worms.
>          > > What primitive(s) do you use to get attended transfer to
>          > > work?  All of the
>          > > proposals (something like 4 of them) work and solve the
>          > > requirement for an
>          > > attended transfer.  Some of these proposals deal more with
>          > > the  bis draft
>          > > (see Tom Taylor's post today).  Everyone seems to want other
>          > > features as
>          > > well, but we need to see at least a "sketch" of the
>          > complete features
>          > > picture associated with each proposal.  This is why I
>          > > proposed the one-day
>          > > face-to-face meeting.
>          > >
>          > > thanks,
>          > > -rohan
>          > >
>          > >
>          > >
>          > > At 12:15 PM 1/9/01 , Sean Olson wrote:
>          > > >I'm sorry, I don't see the standardization of the
>          > > >REFERDONE as being any easier than the standardization
>          > > >of a NOTIFY to serve the same purpose.
>          > > >
>          > > >To satisfy a need stated by Billy, the
>          > > >body of the NOTIFY could simply be the SDP
>          > > >from the 200 OK (assuming an INVITE) or empty
>          > > >for a BYE. Uses of REFER for other methods would
>          > > >need to be specified in extension drafts.
>          > > >The Event: token could be "referdone".
>          > > >
>          > > >Is there anything else that needs to be specified
>          > > >for the use of NOTIFY that I am missing?
>          > > >
>          > > >I don't wish to drag this out forever. I think
>          > > >the solution is fairly simple and straightforward
>          > > >and could be extended in the future.
>          > > >
>          > > >Please point out faults with this proposal and
>          > > >areas of implementation difficulty.
>          > > >/sean
>          > > >
>          > > >Robert Sparks wrote:
>          > > >
>          > > >> a.s. This got a little long - sorry
>          > > >>      It does contain a concrete proposal.
>          > > >> ------------
>          > > >> I think we are falling into a set of traps
>          > > >> with the REFER discussions, endangering an
>          > > >> already overdue deliverable.
>          > > >>
>          > > >> The worst is specification creep. The group
>          > > >> was pretty happy with the functionality of
>          > > >> the current draft. When we tripped up on the
>          > > >> timeout problem, we saw a host of extra
>          > > >> functionality we could add while working
>          > > >> around that problem.
>          > > >>
>          > > >> Most of us have gravitated towards a model
>          > > >> where REFER is answered with a set of
>          > > >> reciprocal responses (essentially NOTIFYs,
>          > > >> possibly of a different name, with or without
>          > > >> an explicit subscribe). What we _haven't_
>          > > >> spent much time on is the profile of those
>          > > >> responses. How many can there be? What do
>          > > >> they contain?
>          > > >>
>          > > >> I really anticipate the answers to those last
>          > > >> questions will vary widely depending on the
>          > > >> application using REFER. We want to be able
>          > > >> to do other things than transfer (this is
>          > > >> why the method got renamed from TRANSFER).
>          > > >> A rich response set for a REFER that triggers
>          > > >> a SUBSCRIBE is likely to be entirely different
>          > > >> in character from one that triggers an INVITE.
>          > > >>
>          > > >>
>          > > >> PROPOSAL
>          > > >> In interests of meeting our working group
>          > > >> deliverable on this topic (now _WAY_ overdue),
>          > > >> I suggest that obtaining this rich response
>          > > >> set has shown itself to be too big a bite. I
>          > > >> propose that it is time to fall back to a single
>          > > >> REFERDONE reciprocal request, carrying the
>          > > >> information that is provided in the current
>          > > >> draft's final response. This would provide a
>          > > >> baseline version of REFER that would meet the
>          > > >> requirements the current draft addresses.
>          > > >>
>          > > >> I further propose that when we complete that work,
>          > > >> we can return to REFER and define an extension that
>          > > >> would get the richer response set, addressing the
>          > > >> current lack of definition of that response set
>          > > >> with something like sip-event profiles.
>          > > >>
>          > > >> RjS
>          > > >>
>          > > >>
>          > > >>
>          > > >> _______________________________________________
>          > > >> SIP mailing list
>          > > >> SIP@lists.bell-labs.com
>          > > >> http://lists.bell-labs.com/mailman/listinfo/sip
>          > > >
>          > > >
>          > > >_______________________________________________
>          > > >SIP mailing list
>          > > >SIP@lists.bell-labs.com
>          > > >http://lists.bell-labs.com/mailman/listinfo/sip
>          > >
>          >
>          >
>          > _______________________________________________
>          > SIP mailing list
>          > SIP@lists.bell-labs.com
>          > http://lists.bell-labs.com/mailman/listinfo/sip
>          >
>         


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 18:46:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23304
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 18:46:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1C17C44359; Tue,  9 Jan 2001 17:47:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 1A02A44355
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 17:46:32 -0500 (EST)
Received: from pm212.warszawa.cvx.ppp.tpnet.pl ([213.76.108.212]:2149 "EHLO
        elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP
	id <S225577AbRAIXqH>; Wed, 10 Jan 2001 00:46:07 +0100
Message-ID: <3A5BA2F5.EBB8A27B@elka.pw.edu.pl>
From: "Piotr S. Kossowski" <P.Kossowski@elka.pw.edu.pl>
Organization: Warsaw University of Technology - Institute of Telecommunications
X-Mailer: Mozilla 4.7 [pl] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Olson <sean.olson@ericsson.com>
Cc: SIP discussion list <sip@lists.bell-labs.com>
Subject: Re: [SIP] different types of URI in 'Contact'
References: <3A5B76EC.6ECAF5C8@elka.pw.edu.pl> <3A5B7F82.2090004@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 00:47:01 +0100
Content-Transfer-Encoding: 7bit

Sean Olson wrote:
> 
> Sending an INVITE with only a mailto: URI in the
> Contact: header(s) is an error situation. The
> purpose of allowing multiple URI types in Contact:
> is really to accommodate their use in redirect (3xx)
> responses. A 302 with a Contact: header containing a
> mailto: URI would, for example, indicate that the
> user is reachable via e-mail at this address. To
> actually contact that user via e-mail, I wouldn't
> send a SIP INVITE of course. I would use SMTP.
> Make sense?
> 

It does make sense, but this is practical point of view.
I thought about conformance with the rfc. To be honest,
I did not notice sentence in style:

"When UAS add 'Contact' header, it  MUST include at least one 'sip:' 
scheme".

So, from formal point of view, using 'ftp:' scheme is allowed ?
Of course it does make no sense. But what to do then with 
"proper ACK destination" problem ?

Piotr

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 19:00:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23401
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 19:00:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 650DF44369; Tue,  9 Jan 2001 18:01:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 24F8644362
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 18:00:02 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA13060;
	Tue, 9 Jan 2001 18:41:55 -0500 (EST)
Message-ID: <3A5BA1C3.D224BA45@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Olson <sean.olson@ericsson.com>
Cc: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        "'Robert Sparks'" <rsparks@dynamicsoft.com>,
        "'Tom-PT Taylor'" <taylor@nortelnetworks.com>,
        "'Rohan Mahy'" <rohan@cisco.com>, sip <sip@lists.bell-labs.com>
Subject: Re: [SIP] REFER progress
References: <E79883AEA37FD411A58C00508BAC5F4B2B5C31@exchange1.nuera.com> <3A5B9DC7.9090308@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 18:41:55 -0500
Content-Transfer-Encoding: 7bit

Sean Olson wrote:
> 
> I have a small problem with this logic. What I am
> proposing is perfectly inline with SUB/NOT and is
> not a radical deviation from it. I argued for implicit
> subscriptions in the SUB/NOT draft specifically for
> this type of situation. With regards to the complexity
> of the solution using NOTIFY, I don't see much difference
> between NOTIFY and REFERDONE in this case. Both will
> need to indicate a final response code. The NOTIFY
> solution happens to use the Event: header. The body
> of the NOTIFY may or may not contain SDP. The
> receiving client of course is free to ignore it.
> I'm not advocating anything like XML be used for this.
> The only modification I would make in a future extension
> would be the support of multiple NOTIFYs and this is
> *very* easily handled by a client that supports a single
> NOTIFY. (Provisional responses in the NOTIFY can simply
> be ignored)
> 
> I'm not going to argue forever on this, I promise :)
> I just would prefer that NOTIFY be used over REFERDONE
> barring any more substantial arguments.
> 

There clearly is no deep technical difference between

REFERDONE

and

NOTIFY
Event: Refer-Done

However, I believe we've tried to make the point in other venues that
events are a fundamental mechanism that has broad applicability. This
smells like an event (as in "let me tell you, something happened") as
opposed to "do something". Thus, I would find it easier to explain the
overall architecture if we consistently labeled (call-related and other)
events as NOTIFY rather than inventing a new method name for each type
of event. By that logic, we should have PRESENT and NOT-PRESENT and
VOICEMAIL-ARRIVED and who knows what else. Can be done, just seems like
it degnerates into an unstructured list of dozens of methods rather than
some logical hierarchy of "this is an event, with a type label".

As has been pointed out in addition, there is no complexity benefit to
limiting notification just to completion of the referred operation. We
may want other status updates in the future and I certainly don't want
to invent a new method for each.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 19:08:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23449
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 19:08:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5043644348; Tue,  9 Jan 2001 18:09:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id B590544341
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 18:08:01 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0A07pT01831
	for sip@lists.bell-labs.com; Tue, 9 Jan 2001 18:07:51 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: sip@lists.bell-labs.com
Subject: Re: [SIP] REFER progress
Message-ID: <20010109180745.B16839@fdd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 18:07:45 -0600

----- Forwarded message from Rick Dean <siplist@fdd.com> -----

Sean,

How does the REFER sender get the REFERDONE/NOTIFY sender
to send an INVITE so the ringback can flow in the right
direction?   Please don't say, "Send another REFER".

Does the REFERDONE/NOTIFY sender have to wait for the
REFERDONE/NOTIFY to complete before he sends a
re-INVITE/BYE?  I have been trying hard not to have 
a message queue.

Internet telephony is usable over 100ms round-trip times.
If we start requiring more than one round trip, signaling
can be noticeably slow.
More messages make the trace files long and complicated.
The error notices get worse:  "packet/state 5
of 9 didn't complete"   More messages gives
people more states to make a bug.  More messages
are harder to test packet loss/reordering cases for.

As for your second point, if I get a re-INVITE after
sending a REFER, I cannot be certain the REFER
failed because the re-INVITE may have crossed
the REFER in transit.  I need a header in the re-INVITE.

--
Rick
Rick_Dean@3com.com

On Tue, Jan 09, 2001 at 05:29:39PM -0600, Sean Olson wrote:
> If I understnnd your concerns correctly, the
> use of an INVITE/BYE instead of NOTIFY buys
> you a couple of things:
> 
> 1) You save the 2 message overhead of NOTIFY/200
> 2) You provide a mechanism to re-establish or
>     end the session between the transferor and
>     transferee based on the outcome of the
>     (blind transfer) REFER.
> 
> The first issue can be solved by my recommendation
> of a Refer-Notify: header that states whether or
> not the transferor wants to be notified of the status
> of the REFER.
> 
> The second issue is independent of whether or not
> NOTIFY is used. In other words, to get the functionality
> you want (as I understand it), you send a REFER without
> a Refer-Notify: header. Then, when the INVITE times out/fails,
> the transferee can send an INVITE/BYE to the transferor as
> you want (in place of the NOTIFY).
> 
> Is there some aspect that I am overlooking (very possible
> since I am dead tired)?
> 
> /sean
> 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 19:29:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA23679
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 19:29:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 66DDA4433F; Tue,  9 Jan 2001 18:30:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 48BE84433C
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 18:29:15 -0500 (EST)
Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0A0SwK08775;
	Tue, 9 Jan 2001 18:28:58 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f0A0PZF20850;
	Tue, 9 Jan 2001 18:25:35 -0600 (CST)
Received: from ericsson.com (pc050184.exu.ericsson.se [138.85.50.184]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA14838; Tue, 9 Jan 2001 18:28:56 -0600 (CST)
Message-ID: <3A5BACC9.7020401@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: "Piotr S. Kossowski" <P.Kossowski@elka.pw.edu.pl>
Cc: SIP discussion list <sip@lists.bell-labs.com>
Subject: Re: [SIP] different types of URI in 'Contact'
References: <3A5B76EC.6ECAF5C8@elka.pw.edu.pl> <3A5B7F82.2090004@ericsson.com> <3A5BA2F5.EBB8A27B@elka.pw.edu.pl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 18:28:57 -0600
Content-Transfer-Encoding: 7bit



Piotr S. Kossowski wrote:


> It does make sense, but this is practical point of view.
> I thought about conformance with the rfc. To be honest,
> I did not notice sentence in style:
> 
> "When UAS add 'Contact' header, it  MUST include at least one 'sip:' 
> scheme".

True. Nor does it say that it is illegal to put the
preamble to the Constitution in the packet. There are
a number of weird cases that are possible. Enumerating
them all in the SIP spec. seems to be overkill.

> 
> So, from formal point of view, using 'ftp:' scheme is allowed ?
> Of course it does make no sense. But what to do then with 
> "proper ACK destination" problem ?
>

In this situation, I would send an ACK, ignoring the
invalid Contact: address followed perhaps by a BYE
(again sent to the original To: URI). Followed by
a DDoS attack on the FTP site.... just kidding of
course.

Alternatively, you could open an FTP session,
search for a vcard, and use the SIP URL in that :)

 
Seriously, you point out a possible error case that
implementations should address. The problem extends
to other possible errors in the final response.
You could argue for different handling depending on
your bent:

1) Ignore the final response (and subsequent erroneous
    final responses) until the INVITE transaction times out.

2) Send an ACK followed by an immediate BYE (which btw is
    a good use for piggybacking :) -- no flames please)

> Piotr
/sean



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 22:13:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA25775
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 22:13:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 513C244338; Tue,  9 Jan 2001 21:14:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16])
	by lists.bell-labs.com (Postfix) with ESMTP id F272D44337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 21:13:18 -0500 (EST)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260)
 id <0G6X00901FLP2G@firewall.mcit.com> for sip@lists.bell-labs.com; Wed,
 10 Jan 2001 03:13:01 +0000 (GMT)
Received: from dgismtp04.wcomnet.com ([166.38.58.144])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0G6X007BVFLPM4@firewall.mcit.com>; Wed,
 10 Jan 2001 03:13:01 +0000 (GMT)
Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262)
 id <0G6X00J01FLP5V@dgismtp04.wcomnet.com>; Wed,
 10 Jan 2001 03:13:01 +0000 (GMT)
Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0G6X00J01FLN5E@dgismtp04.wcomnet.com>;
 Wed, 10 Jan 2001 03:13:01 +0000 (GMT)
Received: from wcom.com ([166.44.56.195])
 by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0G6X00ECJFLITX@dgismtp04.wcomnet.com>; Wed,
 10 Jan 2001 03:12:57 +0000 (GMT)
From: Alan Johnston <alan.johnston@wcom.com>
Subject: Re: [SIP] REFER progress
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: Sean Olson <sean.olson@ericsson.com>,
        "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        "'Robert Sparks'" <rsparks@dynamicsoft.com>,
        "'Tom-PT Taylor'" <taylor@nortelnetworks.com>,
        "'Rohan Mahy'" <rohan@cisco.com>, sip <sip@lists.bell-labs.com>
Message-id: <3A5BD44E.792A720B@wcom.com>
MIME-version: 1.0
X-Mailer: Mozilla 4.7 [en] (Win98; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: en
References: <E79883AEA37FD411A58C00508BAC5F4B2B5C31@exchange1.nuera.com>
 <3A5B9DC7.9090308@ericsson.com> <3A5BA1C3.D224BA45@cs.columbia.edu>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 21:17:35 -0600
Content-Transfer-Encoding: 7bit

I'd be OK with REFER generating an implicit NOTIFY response (instead of
REFERDONE) as long as:

1. This usage of NOTIFY is defined in a document separate from the other
presence stuff (maybe even part of the REFER document).  Our PSTN Gateways
will never implement full presence, but we will want them to support various
types of call transfers using REFER.  Writing requirements for vendors that
say "implement only this piece of this document" is problematic.

2. There are separate event for the progress of the REFERed Request (18x
response received) vs. completion of the REFERed Request (final response -
2xx or failure).  This way, we can implement all the different types of call
transfers in the PSTN, completely blind transfers, transfers where you
disconnect after the target phone rings, and fully attended transfer where
you only disconnect after a successful completion of the transfer.  I'm not
necessarily in favor of multiple NOTIFY per REFER, just that the REFER
should be able to specify which call progress or completion event will
generate the one and only NOTIFY.



Thanks,
Alan Johnston
WorldCom

"Henning G. Schulzrinne" wrote:

> Sean Olson wrote:
> >
> > I have a small problem with this logic. What I am
> > proposing is perfectly inline with SUB/NOT and is
> > not a radical deviation from it. I argued for implicit
> > subscriptions in the SUB/NOT draft specifically for
> > this type of situation. With regards to the complexity
> > of the solution using NOTIFY, I don't see much difference
> > between NOTIFY and REFERDONE in this case. Both will
> > need to indicate a final response code. The NOTIFY
> > solution happens to use the Event: header. The body
> > of the NOTIFY may or may not contain SDP. The
> > receiving client of course is free to ignore it.
> > I'm not advocating anything like XML be used for this.
> > The only modification I would make in a future extension
> > would be the support of multiple NOTIFYs and this is
> > *very* easily handled by a client that supports a single
> > NOTIFY. (Provisional responses in the NOTIFY can simply
> > be ignored)
> >
> > I'm not going to argue forever on this, I promise :)
> > I just would prefer that NOTIFY be used over REFERDONE
> > barring any more substantial arguments.
> >
>
> There clearly is no deep technical difference between
>
> REFERDONE
>
> and
>
> NOTIFY
> Event: Refer-Done
>
> However, I believe we've tried to make the point in other venues that
> events are a fundamental mechanism that has broad applicability. This
> smells like an event (as in "let me tell you, something happened") as
> opposed to "do something". Thus, I would find it easier to explain the
> overall architecture if we consistently labeled (call-related and other)
> events as NOTIFY rather than inventing a new method name for each type
> of event. By that logic, we should have PRESENT and NOT-PRESENT and
> VOICEMAIL-ARRIVED and who knows what else. Can be done, just seems like
> it degnerates into an unstructured list of dozens of methods rather than
> some logical hierarchy of "this is an event, with a type label".
>
> As has been pointed out in addition, there is no complexity benefit to
> limiting notification just to completion of the referred operation. We
> may want other status updates in the future and I certainly don't want
> to invent a new method for each.
> --
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 22:47:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26948
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 22:47:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 147E34433C; Tue,  9 Jan 2001 21:48:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.40.143])
	by lists.bell-labs.com (Postfix) with ESMTP id 4E4AB44337
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 21:47:53 -0500 (EST)
Received: from cs.columbia.edu (adsl-151-198-20-48.nnj.adsl.bellatlantic.net [151.198.20.48])
	by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id WAA12252;
	Tue, 9 Jan 2001 22:46:53 -0500 (EST)
Message-ID: <3A5BDB0B.28CEB745@cs.columbia.edu>
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Johnston <alan.johnston@wcom.com>
Cc: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
        Sean Olson <sean.olson@ericsson.com>,
        "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        "'Robert Sparks'" <rsparks@dynamicsoft.com>,
        "'Tom-PT Taylor'" <taylor@nortelnetworks.com>,
        "'Rohan Mahy'" <rohan@cisco.com>, sip <sip@lists.bell-labs.com>
Subject: Re: [SIP] REFER progress
References: <E79883AEA37FD411A58C00508BAC5F4B2B5C31@exchange1.nuera.com>
	 <3A5B9DC7.9090308@ericsson.com> <3A5BA1C3.D224BA45@cs.columbia.edu> <3A5BD44E.792A720B@wcom.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 09 Jan 2001 22:46:19 -0500
Content-Transfer-Encoding: 7bit



Alan Johnston wrote:
> 
> I'd be OK with REFER generating an implicit NOTIFY response (instead of
> REFERDONE) as long as:
> 
> 1. This usage of NOTIFY is defined in a document separate from the other
> presence stuff (maybe even part of the REFER document).  Our PSTN Gateways
> will never implement full presence, but we will want them to support various
> types of call transfers using REFER.  Writing requirements for vendors that
> say "implement only this piece of this document" is problematic.

This is similar to the other uses of NOTIFY outside presence, such as
the vmail notification and some of the suggested uses in connection with
conferences. I can't see much that needs to be said generically, since
NOTIFY is just another method. (Most of the discussion in the
presence/events documents seems to be about SUBSCRIBE, with NOTIFY
receiving relatively little coverage.) Thus, beyond saying a sentence
about Call-IDs, this should all be contained in the REFER draft.

> 
> 2. There are separate event for the progress of the REFERed Request (18x
> response received) vs. completion of the REFERed Request (final response -
> 2xx or failure).  This way, we can implement all the different types of call
> transfers in the PSTN, completely blind transfers, transfers where you
> disconnect after the target phone rings, and fully attended transfer where
> you only disconnect after a successful completion of the transfer.  I'm not
> necessarily in favor of multiple NOTIFY per REFER, just that the REFER
> should be able to specify which call progress or completion event will
> generate the one and only NOTIFY.

Agreed. It would be easy enough to specify multiple Event labels and
this would be consistent, I believe, with the overall event
architecture. If desired, details can then be encoded as message/sip, as
suggested earlier.

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan  9 22:54:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26965
	for <sip-archive@odin.ietf.org>; Tue, 9 Jan 2001 22:54:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8D95D44348; Tue,  9 Jan 2001 21:55:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id CF46944346
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 21:54:22 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA28880;
	Tue, 9 Jan 2001 22:56:56 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <ZZVFB63A>; Tue, 9 Jan 2001 22:51:11 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BFB97F96@DYN-EXCH-001.dynamicsoft.com>
From: Igor Slepchin <ISlepchin@dynamicsoft.com>
To: "'Piotr S. Kossowski'" <P.Kossowski@elka.pw.edu.pl>,
        SIP discussion list <sip@lists.bell-labs.com>
Subject: RE: [SIP] different types of URI in 'Contact'
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-2"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 22:51:06 -0500

non-SIP URLs are allowed in Contacts of REGISTER requests or redirect
responses, not in INVITEs or responses to INVITEs. 2543bis is fairly
explicit about this, e.g., Contact in INVITE responses is defined as a SIP
address where the UAS is reachable most directly.

---
Igor Slepchin


> -----Original Message-----
> From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl]
> Sent: Tuesday, January 09, 2001 3:39 PM
> To: SIP discussion list
> Subject: [SIP] different types of URI in 'Contact'
> 
> 
> Hello,
> 
> I have got simple question:
> 
> Say that 'Contact' in 200 OK to INVITE req includes only one 
> URI: mailto.
> This is correct according to 'Contact' syntax. Section 11.2 of 
> rfc2543bis-2 says that "(...)'Contact' contains address where 
> the callee
> would like to be contacted fo subsequent transactions, 
> including the ACK
> for the current INVITE". If there is only one URI in the 
> 'Contact' e.g.
> 'mailto:' or 'http:' , how to send ACK to this destination. 
> From technical
> point of view it is easy, but i mean that UAS will never get ACK and
> will have to break just-established call because lack of ACK. 
> Could you correct me ?
> 
> Best Regards, Piotr
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 00:31:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28050
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 00:31:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C97A244337; Tue,  9 Jan 2001 23:32:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web9802.mail.yahoo.com (web9802.mail.yahoo.com [216.136.129.212])
	by lists.bell-labs.com (Postfix) with SMTP id DFF6A44336
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 23:31:01 -0500 (EST)
Message-ID: <20010110053050.98899.qmail@web9802.mail.yahoo.com>
Received: from [203.197.174.36] by web9802.mail.yahoo.com; Tue, 09 Jan 2001 21:30:50 PST
From: laks hmi <lakshmiam@yahoo.com>
To: SIP discussion list <sip@lists.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] Regarding multiple headers
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 9 Jan 2001 21:30:50 -0800 (PST)

hi,

In the rfc *message-header is given.
Does it mean we can allow same header
multiple times ?. i want some clarification on this.

lakshmi


__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 00:54:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28148
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 00:54:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9B6EF44349; Tue,  9 Jan 2001 23:55:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.axestech.com (maxip18.maxipro.com [216.1.203.50])
	by lists.bell-labs.com (Postfix) with ESMTP id E4CD244346
	for <sip@lists.bell-labs.com>; Tue,  9 Jan 2001 23:54:46 -0500 (EST)
Received: from amarreddy (PPP-174-36.bng.vsnl.net.in [203.197.174.36]) by mail.axestech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3)
	id CN7X8TCB; Tue, 9 Jan 2001 23:59:44 -0600
Message-ID: <016d01c07b2a$80d48c70$3e01a8c0@amarreddy>
From: "amar" <kamar@axestech.com>
To: "SIP discussion list" <sip@lists.bell-labs.com>
References: <20010110053050.98899.qmail@web9802.mail.yahoo.com>
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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [SIP] about MIME
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 11:26:38 -0600
Content-Transfer-Encoding: 7bit

Hai all

please let me know if there is any readymade code available for MIME on the
net

Thanks

Amar


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 01:49:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03718
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 01:49:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 14E6644339; Wed, 10 Jan 2001 00:50:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange.satyam.net.in (unknown [202.144.12.32])
	by lists.bell-labs.com (Postfix) with ESMTP id D81B744336
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 00:07:35 -0500 (EST)
Received: from HQBNG01EXFE01.mindtree.com ([202.144.95.250])
	by exchange.satyam.net.in (8.9.3/8.9.3) with ESMTP id LAA22204
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 11:36:46 +0530
Received: from hqbng01ex01.mindtree.com ([172.20.20.4]) by HQBNG01EXFE01.mindtree.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Wed, 10 Jan 2001 11:33:24 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Message-ID: <E34EEFC7FE67BE45A3BC560EEDDBE4A1D37422@hqbng01ex01.mindtree.com>
Thread-Topic: [SIP] Regarding multiple headers
Thread-Index: AcB6xi+jWRau+wbRQ6i/lVvUcjElqgAAl5bA
From: "Mayank Sharma" <mayanks@mindtree.com>
To: "SIP discussion list" <sip@lists.bell-labs.com>
X-OriginalArrivalTime: 10 Jan 2001 06:03:24.0453 (UTC) FILETIME=[0ACCFD50:01C07ACB]
Subject: [SIP] Regarding Multiple Content Types
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 11:33:24 +0530
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA03718

Hi List,
	I have a question about sending a Message body with a
Request/Response. Can I send a Message body with more than one Content Type..
for eg. with the Invite request I might want to send some text/pic along with
the SDP parameters. So I want to send a message body which will have two
differnet content type, application/sdp and text/html for eg. Maybe we can
have a proper demarkation in the message body which will separate the two
different Message types and have two Content-Type header's indicating the
different Content type.

	Please excuse me if this question does not fall in the discussions of
this mailing list.

With Regards,
Mayank Sharma

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 01:51:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04006
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 01:51:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C487A44354; Wed, 10 Jan 2001 00:52:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb14.rediffmail.com (unknown [203.199.83.22])
	by lists.bell-labs.com (Postfix) with SMTP id 66C0644351
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 00:51:05 -0500 (EST)
Received: (qmail 29418 invoked by uid 510); 10 Jan 2001 06:46:17 -0000
Message-ID: <20010110064617.29417.qmail@mailweb14.rediffmail.com>
Received: from unknown (203.197.200.47) by rediffmail.com via HTTP; 10 Jan 2001 06:46:17 -0000
MIME-Version: 1.0
To: "lakshmiam@yahoo.com" <lakshmiam@yahoo.com>,
        "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
Subject:  Re: [SIP] Regarding multiple headers
From: "Deepak  Mohan" <deepakwarrier@rediffmail.com>
Content-ID: <Wed_Jan_10_12_16_17_IST_2001_0@mailweb14.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 10 Jan 2001 06:46:17 -0000
Content-Transfer-Encoding: 7bit

Yes, You can have the same header more than once.
You can have 
QT:

Accept: application/sdp;level=1, application/x-private, text/html

UQT:

or you can have it as
QT:

Accept: application/sdp;level=1
Accept: application/x-private
Accept: text/html


UQT:

I think this is mentioned somewhere in the rfc or draft.
It also might be required to keep in mind that some other header might come between two "Accept"s. Comments, anyone?

Deepak


------------- Original Message --------------
laks hmi <lakshmiam@yahoo.com> wrote:
To:SIP discussion list <sip@lists.bell-labs.com>
From:laks hmi <lakshmiam@yahoo.com>
Date:Tue, 9 Jan 2001 21:30:50 -0800 (PST)
Subject:[SIP] Regarding multiple headers

hi,

In the rfc *message-header is given.
Does it mean we can allow same header
multiple times ?. i want some clarification on this.

lakshmi


__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 02:02:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08981
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 02:02:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 76C334435E; Wed, 10 Jan 2001 01:03:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id 80A524435D
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 01:02:45 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f0A724d20076;
	Wed, 10 Jan 2001 08:02:04 +0100 (MET)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.64])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA23535;
	Wed, 10 Jan 2001 09:02:04 +0200 (EET)
Message-ID: <3A5C08E8.AF713BF5@lmf.ericsson.se>
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
Cc: Deepak Mohan <deepakwarrier@rediffmail.com>,
        "lakshmiam@yahoo.com" <lakshmiam@yahoo.com>
Subject: Re: [SIP] Regarding multiple headers
References: <20010110064617.29417.qmail@mailweb14.rediffmail.com>
Content-Type: multipart/mixed;
 boundary="------------5C6AC312D2A0781A6D37C8BE"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 09:02:00 +0200

This is a multi-part message in MIME format.
--------------5C6AC312D2A0781A6D37C8BE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

>Yes, You can have the same header more than once.
>You can have
>QT:
> 
>Accept: application/sdp;level=1, application/x-private, text/html
> 
>UQT:
> 
>or you can have it as
>QT:
> 
>Accept: application/sdp;level=1
>Accept: application/x-private
>Accept: text/html
> 
>UQT:
> 
>I think this is mentioned somewhere in the rfc or draft.
>It also might be required to keep in mind that some other header might >come between two "Accept"s. Comments, anyone?

Actually, what you say is not correct.

The Accept header is used only to indicate which kind of message bodies
you accept, and (like the RFC says) can be used in 415 (Unsupported
Media Type) responses.

When you want to actually include multiple message bodies in your
message you can use Content-Type: multipart/mixed to indicate that, and
then use MIME, in which you then have a separate Content-Type header for
each message body you send. 

Regards,

Christer Holmberg
Ericsson Finland







 
>Deepak
> 
> ------------- Original Message --------------
> laks hmi <lakshmiam@yahoo.com> wrote:
> To:SIP discussion list <sip@lists.bell-labs.com>
> From:laks hmi <lakshmiam@yahoo.com>
> Date:Tue, 9 Jan 2001 21:30:50 -0800 (PST)
> Subject:[SIP] Regarding multiple headers
> 
> hi,
> 
> In the rfc *message-header is given.
> Does it mean we can allow same header
> multiple times ?. i want some clarification on this.
> 
> lakshmi
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Photos - Share your holiday photos online!
> http://photos.yahoo.com/
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 
> _____________________________________________________
> Chat with your friends as soon as they come online. Get Rediff Bol at
> http://bol.rediff.com
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
--------------5C6AC312D2A0781A6D37C8BE
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------5C6AC312D2A0781A6D37C8BE--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 02:26:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11644
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 02:26:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D823E44343; Wed, 10 Jan 2001 01:27:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb15.rediffmail.com (unknown [203.199.83.23])
	by lists.bell-labs.com (Postfix) with SMTP id 7DF2244336
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 01:26:38 -0500 (EST)
Received: (qmail 8693 invoked by uid 510); 10 Jan 2001 07:19:54 -0000
Message-ID: <20010110071954.8692.qmail@mailweb15.rediffmail.com>
Received: from unknown (203.197.200.47) by rediffmail.com via HTTP; 10 Jan 2001 07:19:54 -0000
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
From: "Deepak  Mohan" <deepakwarrier@rediffmail.com>
Content-ID: <Wed_Jan_10_12_49_53_IST_2001_0@mailweb15.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Subject: [SIP] Proxys and authenticated fields
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 10 Jan 2001 07:19:54 -0000
Content-Transfer-Encoding: 7bit


"6 Header field definitions" in draft-ietf-sip-rfc2543bis-02 has a line "Proxies MUST NOT alter any fields that are authenticated (see Section 13.2), but MAY add copies of fields that were authenticated by the UA
if indicated in the table".

Could somebody please explain the "add copies of fields that were authenticated" part?

Thanks,
Deepak


_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 02:39:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11775
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 02:39:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BA20944341; Wed, 10 Jan 2001 01:40:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb15.rediffmail.com (unknown [203.199.83.23])
	by lists.bell-labs.com (Postfix) with SMTP id D64E54433F
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 01:39:52 -0500 (EST)
Received: (qmail 27108 invoked by uid 510); 10 Jan 2001 07:33:09 -0000
Message-ID: <20010110073309.27107.qmail@mailweb15.rediffmail.com>
Received: from unknown (203.197.200.47) by rediffmail.com via HTTP; 10 Jan 2001 07:33:09 -0000
MIME-Version: 1.0
To: "christer.holmberg@lmf.ericsson.se" <christer.holmberg@lmf.ericsson.se>,
        "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
Subject:  Re: Re: [SIP] Regarding multiple headers
Cc: "lakshmiam@yahoo.com" <lakshmiam@yahoo.com>
From: "Deepak  Mohan" <deepakwarrier@rediffmail.com>
Content-ID: <Wed_Jan_10_13_03_08_IST_2001_0@mailweb15.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 10 Jan 2001 07:33:09 -0000
Content-Transfer-Encoding: 7bit


Hi,
 For the original poster's question

> In the rfc *message-header is given.
> Does it mean we can allow same header
> multiple times ?. i want some clarification on this.

My reply is correct.
You can have multiple "Accept"s in an INVITE to inform the callee what format the "Content-type" of it's response SHOULD be in. Please note that what is being discussed here is "*message-header", and not "message-body". However, your post seems to answer the  "Regarding Multiple Content Types" thread.

Thanks,
Deepak 
------------- Original Message --------------
Christer Holmberg <christer.holmberg@lmf.ericsson.se> wrote:
To:"sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
From:Christer Holmberg <christer.holmberg@lmf.ericsson.se>
Date:Wed, 10 Jan 2001 09:02:00 +0200
CC:Deepak Mohan <deepakwarrier@rediffmail.com>,
"lakshmiam@yahoo.com" <lakshmiam@yahoo.com>
Subject:Re: [SIP] Regarding multiple headers


Hi,

>Yes, You can have the same header more than once.
>You can have
>QT:
> 
>Accept: application/sdp;level=1, application/x-private, text/html
> 
>UQT:
> 
>or you can have it as
>QT:
> 
>Accept: application/sdp;level=1
>Accept: application/x-private
>Accept: text/html
> 
>UQT:
> 
>I think this is mentioned somewhere in the rfc or draft.
>It also might be required to keep in mind that some other header might >come between two "Accept"s. Comments, anyone?

Actually, what you say is not correct.

The Accept header is used only to indicate which kind of message bodies
you accept, and (like the RFC says) can be used in 415 (Unsupported
Media Type) responses.

When you want to actually include multiple message bodies in your
message you can use Content-Type: multipart/mixed to indicate that, and
then use MIME, in which you then have a separate Content-Type header for
each message body you send. 

Regards,

Christer Holmberg
Ericsson Finland







 
>Deepak
> 
> ------------- Original Message --------------
> laks hmi <lakshmiam@yahoo.com> wrote:
> To:SIP discussion list <sip@lists.bell-labs.com>
> From:laks hmi <lakshmiam@yahoo.com>
> Date:Tue, 9 Jan 2001 21:30:50 -0800 (PST)
> Subject:[SIP] Regarding multiple headers
> 
> hi,
> 
> In the rfc *message-header is given.
> Does it mean we can allow same header
> multiple times ?. i want some clarification on this.
> 
> lakshmi


_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 02:47:21 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA11830
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 02:47:21 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 57B084436B; Wed, 10 Jan 2001 01:46:07 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id EAE674435B
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 01:45:46 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f0A7isd13350;
	Wed, 10 Jan 2001 08:44:54 +0100 (MET)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.64])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA25924;
	Wed, 10 Jan 2001 09:44:52 +0200 (EET)
Message-ID: <3A5C12EE.D00DD1E8@lmf.ericsson.se>
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
Cc: Deepak Mohan <deepakwarrier@rediffmail.com>,
        "lakshmiam@yahoo.com" <lakshmiam@yahoo.com>
Subject: Re: [SIP] Regarding multiple headers
References: <20010110073309.27107.qmail@mailweb15.rediffmail.com>
Content-Type: multipart/mixed;
 boundary="------------377C3E1CBC8378A67E667858"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 09:44:46 +0200

This is a multi-part message in MIME format.
--------------377C3E1CBC8378A67E667858
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

>Hi,
> For the original poster's question
> 
>>In the rfc *message-header is given.
>>Does it mean we can allow same header
>>multiple times ?. i want some clarification on this.
> 
>My reply is correct.
>You can have multiple "Accept"s in an INVITE to inform the callee what format the "Content-type" of it's >response SHOULD be in. Please note that what is being discussed here is "*message-header", and not >"message-body". However, your post seems to answer the  "Regarding Multiple Content Types" thread.

True. I guess I replied to the wrong mail. Sorry, my misstake :)

Christer Holmberg
Ericsson Finland



> 
> Thanks,
> Deepak
> ------------- Original Message --------------
> Christer Holmberg <christer.holmberg@lmf.ericsson.se> wrote:
> To:"sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
> From:Christer Holmberg <christer.holmberg@lmf.ericsson.se>
> Date:Wed, 10 Jan 2001 09:02:00 +0200
> CC:Deepak Mohan <deepakwarrier@rediffmail.com>,
> "lakshmiam@yahoo.com" <lakshmiam@yahoo.com>
> Subject:Re: [SIP] Regarding multiple headers
> 
> Hi,
> 
> >Yes, You can have the same header more than once.
> >You can have
> >QT:
> >
> >Accept: application/sdp;level=1, application/x-private, text/html
> >
> >UQT:
> >
> >or you can have it as
> >QT:
> >
> >Accept: application/sdp;level=1
> >Accept: application/x-private
> >Accept: text/html
> >
> >UQT:
> >
> >I think this is mentioned somewhere in the rfc or draft.
> >It also might be required to keep in mind that some other header might >come between two "Accept"s. Comments, anyone?
> 
> Actually, what you say is not correct.
> 
> The Accept header is used only to indicate which kind of message bodies
> you accept, and (like the RFC says) can be used in 415 (Unsupported
> Media Type) responses.
> 
> When you want to actually include multiple message bodies in your
> message you can use Content-Type: multipart/mixed to indicate that, and
> then use MIME, in which you then have a separate Content-Type header for
> each message body you send.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> >Deepak
> >
> > ------------- Original Message --------------
> > laks hmi <lakshmiam@yahoo.com> wrote:
> > To:SIP discussion list <sip@lists.bell-labs.com>
> > From:laks hmi <lakshmiam@yahoo.com>
> > Date:Tue, 9 Jan 2001 21:30:50 -0800 (PST)
> > Subject:[SIP] Regarding multiple headers
> >
> > hi,
> >
> > In the rfc *message-header is given.
> > Does it mean we can allow same header
> > multiple times ?. i want some clarification on this.
> >
> > lakshmi
> 
> _____________________________________________________
> Chat with your friends as soon as they come online. Get Rediff Bol at
> http://bol.rediff.com
--------------377C3E1CBC8378A67E667858
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------377C3E1CBC8378A67E667858--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 03:23:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12138
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 03:23:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E49844433B; Wed, 10 Jan 2001 02:24:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web9807.mail.yahoo.com (web9807.mail.yahoo.com [216.136.129.32])
	by lists.bell-labs.com (Postfix) with SMTP id A6F4C44336
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 02:23:32 -0500 (EST)
Message-ID: <20010110082320.82654.qmail@web9807.mail.yahoo.com>
Received: from [203.197.174.36] by web9807.mail.yahoo.com; Wed, 10 Jan 2001 00:23:20 PST
From: laks hmi <lakshmiam@yahoo.com>
Subject: Re: [SIP] Regarding multiple headers
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
Cc: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 00:23:20 -0800 (PST)

hi,

If we r supporting multiple headers (*message-hdr), 
then is it a MUST to have server list?. 
can u pl explain this in little detail.

Regards
lakshmi






--- Christer Holmberg
<christer.holmberg@lmf.ericsson.se> wrote:
> 
> Hi,
> 
> >Yes, You can have the same header more than once.
> >You can have
> >QT:
> > 
> >Accept: application/sdp;level=1,
> application/x-private, text/html
> > 
> >UQT:
> > 
> >or you can have it as
> >QT:
> > 
> >Accept: application/sdp;level=1
> >Accept: application/x-private
> >Accept: text/html
> > 
> >UQT:
> > 
> >I think this is mentioned somewhere in the rfc or
> draft.
> >It also might be required to keep in mind that some
> other header might >come between two "Accept"s.
> Comments, anyone?
> 
> Actually, what you say is not correct.
> 
> The Accept header is used only to indicate which
> kind of message bodies
> you accept, and (like the RFC says) can be used in
> 415 (Unsupported
> Media Type) responses.
> 
> When you want to actually include multiple message
> bodies in your
> message you can use Content-Type: multipart/mixed to
> indicate that, and
> then use MIME, in which you then have a separate
> Content-Type header for
> each message body you send. 
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> 
> 
> 
> 
>  
> >Deepak
> > 
> > ------------- Original Message --------------
> > laks hmi <lakshmiam@yahoo.com> wrote:
> > To:SIP discussion list <sip@lists.bell-labs.com>
> > From:laks hmi <lakshmiam@yahoo.com>
> > Date:Tue, 9 Jan 2001 21:30:50 -0800 (PST)
> > Subject:[SIP] Regarding multiple headers
> > 
> > hi,
> > 
> > In the rfc *message-header is given.
> > Does it mean we can allow same header
> > multiple times ?. i want some clarification on
> this.
> > 
> > lakshmi
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Photos - Share your holiday photos online!
> > http://photos.yahoo.com/
> > 
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> >
>
_____________________________________________________
> > Chat with your friends as soon as they come
> online. Get Rediff Bol at
> > http://bol.rediff.com
> > 
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip>
begin:vcard 
> n:Holmberg;Christer
> tel;cell:+358-40-5604412
> tel;work:+358-9-2992943
> x-mozilla-html:FALSE
> org:Ericsson;IP Multimedia / Advanced Signalling
> Research Laboratory
> adr:;;;;;;
> version:2.1
> email;internet:christer.holmberg@lmf.ericsson.se
> title:System Designer
> fn:Christer Holmberg
> end:vcard
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 04:09:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12448
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 04:09:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 82E084433A; Wed, 10 Jan 2001 03:10:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id 991CA44336
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 03:09:13 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 10 Jan 2001 09:09:02 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id JAA29440; Wed, 10 Jan 2001 09:07:25 GMT
From: "Jo Hornsby" <jhornsby@ubiquity.net>
To: "Sean Olson" <sean.olson@ericsson.com>,
        "Piotr S. Kossowski" <P.Kossowski@elka.pw.edu.pl>
Cc: "SIP discussion list" <sip@lists.bell-labs.com>
Subject: RE: [SIP] different types of URI in 'Contact'
Message-ID: <003901c07ae4$bf386450$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <3A5BACC9.7020401@ericsson.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 09:07:24 -0000
Content-Transfer-Encoding: 7bit

Sean Olson wrote:
>
> Piotr S. Kossowski wrote:
> 
> > It does make sense, but this is practical point of view.
> > I thought about conformance with the rfc. To be honest,
> > I did not notice sentence in style:
> > 
> > "When UAS add 'Contact' header, it  MUST include at least one 'sip:' 
> > scheme".
> 
> True. Nor does it say that it is illegal to put the
> preamble to the Constitution in the packet. There are
> a number of weird cases that are possible. Enumerating
> them all in the SIP spec. seems to be overkill.

Indeed.  However, this case is explicitly addressed.
Section 2.2 of the current bis2 says:

 In the following locations, only SIP URLs are allowed:

        o Request-URI in a REGISTER request;

        o Contact header field in INVITE, OPTIONS and BYE and 2xx
          responses.

HTH,


 - Jo.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 04:25:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12556
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 04:25:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E09D74434C; Wed, 10 Jan 2001 03:26:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web9801.mail.yahoo.com (web9801.mail.yahoo.com [216.136.129.211])
	by lists.bell-labs.com (Postfix) with SMTP id D1D1B44336
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 03:25:58 -0500 (EST)
Message-ID: <20010110092547.67157.qmail@web9801.mail.yahoo.com>
Received: from [203.197.174.36] by web9801.mail.yahoo.com; Wed, 10 Jan 2001 01:25:47 PST
From: laks hmi <lakshmiam@yahoo.com>
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] Regarding SIP-URL
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 01:25:47 -0800 (PST)

Hi,

In rfc, they have told to exclude the delimiters used
for Request-URI inside . But in the authorize and
authenticate headers, SIP-URL is coming in cotes, but
cotes is also coming in the telphone-subscirber. 

pl clarify this.

lakshmi



__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 05:18:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12764
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 05:18:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0E8134433F; Wed, 10 Jan 2001 04:19:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61])
	by lists.bell-labs.com (Postfix) with ESMTP id 48C3C4433E
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 04:18:13 -0500 (EST)
Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc363f43d51049eec4d@cvis29.marconicomms.com>;
 Wed, 10 Jan 2001 10:17:55 +0000
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-30) id KAA03638; Wed, 10 Jan 2001 10:17:55 GMT
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 802569D0.003888F2 ; Wed, 10 Jan 2001 10:17:30 +0000
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Keith Robinson" <Keith.Robinson@marconi.com>
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
Cc: sip@lists.bell-labs.com, Steve Levy <stlevy@cisco.com>
Message-ID: <802569D0.003887E7.00@marconicomms.com>
Subject: Re: [SIP] Overlap Sending
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=te14iDPNZKH2CM9vaPShphOXAtxVappiaHVLtVzdnm5s1zCOyhl9pDg6"
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 10:17:36 +0000

--0__=te14iDPNZKH2CM9vaPShphOXAtxVappiaHVLtVzdnm5s1zCOyhl9pDg6
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



If we say that the 484 clears down the call attempt and therefore associated
state in the preceding
SIP nodes then I have no problem with generating a new initial INVITE with a new
TO header; this
seems consistent with the RFC. Note that the paragraph in section 4.2.1 starting
"A UAS acting as a gateway.."
implies that the UAS that generated the 484 does not kill associated state with
this call attempt.

So, the problem I have with using the same Call-Id though  is
that it is unclear from the RFC what a UAS will make of the received request.
Referring to section 11.5
we get to case 3, where a request has been received with a Call-Id that matches
a current; however
case 3 only explains the meaning of the request if the To and From fields match
stored values at this point, -
"the request is a new transaction for an existing leg", it does not explain what
it means if either the From or To
fields are differ. Is it an update to either field ? Is it a request for a new
leg ? Is it erroneous. I have raised this
as a seperate question on the list as it is probably a more general problem.

I think it is therefore safest for the 484 to kill that call attempt and
associated state completely, including
within the terminating UAS that generated it. INVITES carrying the subsequent
digits (plus original digits)
in the TO field will  then be treated as brand new call attempts with no
ambiguity.

I am not advocating that this is the best solution, just the safest without
significant change to the RFC.

As I said previously, I believe a better solution would be to able to send
re-INVITES after an infomational
response, but before the final ACK. Of course, this would mean the TO field has
to remain consistent for all
these re-INVITES so could not be used to carry the subsequent digits.........

Advive on this matter from the SIP authors would be gratefully appreciated.

Regards,

K. Robinson.









Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 09/01/2001 10:50:06
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:      sip@lists.bell-labs.com                             
                                                              
 cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy          
          <stlevy@cisco.com>                                  
                                                              
                                                              
                                                              
 Subject: Re: [SIP] Overlap Sending                           
                                                              








Hi,

>I take your point about requiring a proxy to route 6543231@sipgw.com the same
>way as 65432@sipgw.com but I believe this to be entirely within the routing
data
>set up by the administration. Allowing clients to choose there own path through
the
>network to get to their desired destination using various digit sequences seems
like the
>classic way of exposing networks to fraudulent use (billing avoidance,
bypassing security,
>etc). However, I think this is a seperate issue.

Well, it's related :)

>I am still concerned about the Route header overwriting the R-URI and therefore
>destroying the subsequent digits when subsequent messages are routed using the
Route header mechanism. I
>am not sure that putting the subsequent digits in the TO header helps because I
believe the TO
>URL is supposed to be invariant during the lifetime of the call leg.

Well, this depends a little on how you define a call leg, I guess...
Since you got a 4xx response to your first INVITE, you didn't manage to
set up a call leg, so then you try to set up a "new" call leg - with a
new R-URI and To header...

INVITE 123@sipgw.com
To: 123@sipgw.com

<---- 484 -----

INVITE 123456@sipgw.com
To: 123456@sipgw.com

>Modifying the TO URL after the initial INVITE I think will cause problems for
proxies  that are using the TO >URL to match subsequent requests to call legs in
progress.

Since the proxy sent back 484, I wouldn't consider the call leg to be in
progress anymore (after the proxy receive the ACK, that is).

And, the proxy will probably have to do the routing based on the To
header, since the R-URI will probably (unless we use an outbound proxy)
be the address of the proxy itself, so if the To header isn't changed
the proxy will try to route 123@sipgw.com every time, even if more
digits have provided by the client. And, if the proxy is supposed to
"combine" the Current-Dial-String header value with the To header, to be
able to route, I think that the client could put the new value in the To
header from the beginning. Because, if the proxy doesn't support the
Current-Dial-String it wouldn't be able to do anything, since both the
R-URI and To header could be the same in the subsequent INVITEs. If you
have a updated To header, and the proxy doesn't support the digitmap, it
would at least be able to route the new To header - even if the message
may take a "wrong" route.

>Without introducing a new header to carry the digit string, then I think the
>only other way to make overlap sending work is for the 484 to clear down the
call leg as other 4XX
>responses do and subsequent INVITES with the original digits + additional
digits to be a new INVITE (with a
>new Call-Id).

I agree, but I don't think it requires a new Call-Id. Then we could
still define a digitmap header to make sure  (if it is supported by the
proxy) that the proxy will always route the message correctly, no matter
how many INVITEs you need to provide all digits.

>The initial INVITE will not be routed using Route headers, so the digit string
in the R-URI will
>not be lost.

Proxies may change the R-URI...

>There still could be a problem if the client has built a Route header (learnt
out-of-band) and puts
>this in the initial INVITE; the same problem may occur.

This will not be a problem if all servers in the path support the
digitmap... :)

>Without clarification of this matter in the bis draft then I don't think
overlap
>sending is going to be interoperable.

I agree.

Personally I think (no, this is NOT a proposal to re-write SIP :) the
best way would be to have some kind of "multi-message" setup, and that
would also solve a number of other issues (i.e. ISUP transparency).

Regards,

Christer Holmberg
Ericsson Finland






Keith Robinson wrote:
>
> Let's consider the following point:
>
> "I don't know. I haven't seen a proxy that would route depending on the
> user, but it COULD happend. Let's assume , for example, that you do a
> SRV DNS lookup, and get a list of servers. Then you MAY choose a
> different server, for load balance purpose e.g., depending on the user
> name. Just an example..."
>
> One way of ensuring that subsequent requests always traverse a given SIP
> node is for that node to Record-Route or supply a Contact ; it is likely that
> proxies and
> UAS at PSTN interworking points will require to stay in the signalling path
> during
> call setup so will do so.  Now, suppose one such node receives an initial
INVITE
> with
> a R-URI of sip:654@sipgw.com and creates a Contact header thus:
>
> Contact: sip:654@sipgw.com;maddr=sipgw.com
>
> This is then returned in the 484 response so that the sending UA may build a
> Route header from it. Here is my first concern; will the sending UA treat the
> subsequent INVITE as a subsequent INVITE or as a new INVITE on a new
> Call-Id ? I ask because the 484 response is non-200 final response which
> implies that that call attempt has failed; obviously in this case it hasn't
> failed
> (not yet, anyway) its just been partially set up.  Does this lead to special
> case handling
> for a particular 4XX response ? In fact, the 484 is almost like an
informational
> response.
> Would it be better to send an informational response (say 183) and the spec
> updated to
> allow subsequent INVITEs to be sent before the final ACK (a point raised by J.
> Rosenberg
> earlier on the list, but in a different context - to convey updated SDP
> information).
>
> Assuming the above is resolved one way or another, then a SIP node preceding
> sipgw.com is going to receive a subsequent INVITE for this call (containing
> additional
> digits 321)  that will look something like:
>
> INVITE sip:321@preceding.sipgw.com
> Route: sip:654@sipgw.com;maddr=sipgw.com
>
> As a Route header is present, this will be used to route the INVITE so
> therefore sipgw.com will receive an INVITE with the following Request
> Line:
>
> INVITE sip:654@sipgw.com;maddr=sipgw.com
>
> And here is a more worrying problem, the subsequent digits have been lost.
> The situation would be no better if the subsequent INVITE contained original
> digits
> plus subsequent digits; they would still be lost.
>
> The problem stems from the fact that the R-URI is supposed to be invariant at
> each
> node during the lifetime of the call leg, yet to do overlap sending it is
being
> used to
> convey new information so therefore does not remain invariant and other parts
of
> the
> protocol which assume it is invariant e.g., routing using the Route header
> break.
>
> Using a TEL URL does not help either; the digits would still be lost after the
> popping of
> the Route entry into the R-URI.
>
> It would be easier to implement overlap sending if a seperate header could be
> used to
> convey the dialled digits, so an original INVITE may look something like:
>
> INVITE sip:digitdecode@sipgw.com
> Current-Dial-String: 01623
>
> The subsequent INVITES would then look something like:
>
> INVITE sip:digitdecode@sipgw.com;maddr=sipgw.com
> Current-Dial-String: 01623654398
>
> This ties in with your point of implementing a digit map header.
>
> Regards,
>
> K. Robinson.
>
> Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 13:40:47
>
>
>
>
>
>
>
>  To:      sip@lists.bell-labs.com
>
>  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
>           <stlevy@cisco.com>
>
>
>
>  Subject: Re: [SIP] Overlap Sending
>
>
> Hi,
>
> >If a proxy, not serving uas.com, receives an INVITE with a R-URI of
4@uas.com,
> >why would it route it differently (Route headers not withstanding) from an
> INVITE
> >with a R-URI of 441@uas.com ?
>
> I don't know. I haven't seen a proxy that would route depending on the
> user, but it COULD happend. Let's assume , for example, that you do a
> SRV DNS lookup, and get a list of servers. Then you MAY choose a
> different server, for load balance purpose e.g., depending on the user
> name. Just an example...
>
> And, what happen if you use a TEL-URL, where you have to route depending
> on the user name (=telephone number). I guess using a ENUM DNS lookup
> COULD route it to the same host, but then I guess you would have to
> configure your DNS to for all the possible combinations (4.e164.arpa,
> 44.e164.arpa and 441.e164.arpa)...
>
> >Surely, if the proxy does not serve the domain identified in the R-URI it
> cannot
> >make any routing decisions based on the user part of the R-URI.
> >If, on the other hand, the proxy does serve uas.com, then it will be involved
> in
> >routing the call using the dialled digit string and I would expect it to know
> such things as minimum digits to
> >translation and perhaps even maximum number of digits to follow. Also,
because
> the proxy is doing digit based
> >routing it must be subject to the requirements of overlap sending so I would
> expect it to be stateful, at >least until call setup is complete, in which
case
> remembering previous call information would be reasonable. >In fact, such a
> proxy appears much like the interworking UAs I referred to previously and to
> which my question >applies.
>
> That was my point - that you also have to have support for this in your
> proxies, and not only in your client.
>
> I think the issue is that there are lots of what-ifs involved in this,
> and it should be specified how the specific cases are handled -
> especially by proxies and redirect servers.
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
> > Regards,
> >
> > K. Robinson
> >
> > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
> >
> >
> >
> >
> >
> >
> >
>
> Keith Robinson wrote:
> >
> > If a proxy, not serving uas.com, receives an INVITE with a R-URI of
4@uas.com,
> > why
> > would it route it differently (Route headers not withstanding) from an
INVITE
> > with a R-URI of 441@uas.com ?
> > Surely, if the proxy does not serve the domain identified in the R-URI it
> cannot
> > make any
> > routing decisions based on the user part of the R-URI.
> >
> > If, on the other hand, the proxy does serve uas.com, then it will be
involved
> in
> > routing the call using the dialled
> > digit string and I would expect it to know such things as minimum digits to
> > translation and perhaps even
> > maximum number of digits to follow. Also, because the proxy is doing digit
> based
> > routing it must be subject to the
> > requirements of overlap sending so I would expect it to be stateful, at
least
> > until call setup is complete, in which
> > case remembering previous call information would be reasonable. In fact,
such
> a
> > proxy appears much like the
> > interworking UAs I referred to previously and to which my question applies.
> >
> > Regards,
> >
> > K. Robinson
> >
> > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
> >
> >
> >
> >
> >
> >
> >
> >  To:      sip@lists.bell-labs.com
> >
> >  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
> >           <stlevy@cisco.com>
> >
> >
> >
> >  Subject: Re: [SIP] Overlap Sending
> >
> >
> > Hi,
> >
> > I think sending re-INVITES containing only subsequent digits will create
> > some problems. It's not enough that the UAS remembers the previous
> > INVITEs for the specific Call-ID, you may also have intermediate
> > redirect- and/or proxy servers that make their redirect/forwarding
> > decissions based on the destination number, and then they would also
> > have to remember the previous INVITEs, and they would possible also have
> > to be able to know if, and in some cases, how many digits will follow
> > (e.g. 4@uas.com may be routed to a complete destination than
> > 441@uas.com, etc.) Maybe we should implement some kind of digit-map
> > header, or something... :)
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> > Keith Robinson wrote:
> > >
> > > Yes, this is the type of case I have in mind. The question I have is what
> are
> > > the subsequent INVITES; are they
> > >
> > > a) New INVITES, on a new Call-Id containing the original digits (from
> original
> > > INVITE) + subsequent digits ?
> > >
> > > or
> > >
> > > b) re-INVITES containing only subsequent digits ?
> > >
> > > or
> > >
> > > c) re-INVITES containing original digits + subsequent digits ?
> > >
> > > The sending UAs I referred to in my previous note are those that sit in
> > PSTN/SIP
> > > gateways,
> > > not necessarily an originating UA sitting on someones desktop.
> > >
> > > So, the question applies as much to these interworking UAs for
constructing
> > > the subsequent INVITEs as well as to receiving UAs for interpreting them.
> > >
> > > Regards,
> > >
> > > K. Robinson.
> > >
> > > Steve Levy <stlevy@cisco.com> on 05/01/2001 22:32:00
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  To:      Keith Robinson/MAIN/MC1@MCMAIN,
> > >           sip@lists.bell-labs.com
> > >
> > >  cc:
> > >
> > >
> > >
> > >  Subject: Re: [SIP] Overlap Sending
> > >
> > >
> > > Hi Keith,
> > >
> > > I was wondering if in considering overlap sending issues and SIP if you
were
> > > considering the case of overlap sending across multiple networks with
> variable
> > > length digits.
> > >
> > > In this case, in order to avoid post dial delay, the digits need to be
> passed
> > > through the networks to the final destiantion network prior to end of dial
> > > (since the destination network is the only network that knows how many
> digits
> > > are required). So in effect there may be additional digits sent after an
> > INVITE
> > > has been received and sent downstream to the callee.
> > >
> > > Thanks,
> > > Steve
> > >
> > > At 03:50 PM 1/5/01 +0000, Keith Robinson wrote:
> > > >
> > > >
> > > >I have the following query regarding overlap sending as defined in
> > > >rfc2543bis-02:
> > > >
> > > >Section 4.2.1 states the following:
> > > >
> > > >"...the UAS compares the Request-URI with Request-URI of the previous
> INVITE
> > > >request
> > > >for the same Call-Id. If the Request-URI  contains additional digits in
the
> > > >'user' part, the UAS
> > > >treats the INVITE as adding additional digits to the original dialed
> string."
> > > >
> > > >This appears to imply that the subsequent INVITE contains the original
> > dialled
> > > >string plus the
> > > >additional digits; if this is the case, then there is no need for the UAS
> to
> > > >remember the
> > > >previous string, and therefore no need to keep any state regarding the
> > previous
> > > >attempt.
> > > >The subsequent INVITE can really be a new INVITE., i.e. a new Call-Id.
> > > >
> > > >If, on the other hand, the sending UA only sends additional digits, then
> the
> > > >original digits
> > > >will have to be remembered by the UAS, and the INVITE matched up with
this
> > > >state
> > > >so
> > > >this INVITE must be on the same Call-Id.
> > > >
> > > >This latter case is similar to the way existing telephony protocols
> transmit
> > > >addtional digits
> > > >when doing overlap sending.
> > > >
> > > >So, upon receiving a response of 484 Address Incomplete, does the sending
> UA
> > > >send
> > > >original digits plus aditional digits on a new Call-Id or additional
digits
> > > >only
> > > >on the same
> > > >Call-Id with an incremented Cseq.
> > > >
> > > >Regards,
> > > >
> > > >K. Robinson.
> > > >
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >SIP mailing list
> > > >SIP@lists.bell-labs.com
> > > >http://lists.bell-labs.com/mailman/listinfo/sip
> > >
> > > _______________________________________________
> > > SIP mailing list
> > > SIP@lists.bell-labs.com
> > > http://lists.bell-labs.com/mailman/listinfo/sip
> > >
> > > _______________________________________________
> > > SIP mailing list
> > > SIP@lists.bell-labs.com
> > > http://lists.bell-labs.com/mailman/listinfo/sip

--0__=te14iDPNZKH2CM9vaPShphOXAtxVappiaHVLtVzdnm5s1zCOyhl9pDg6
Content-type: application/octet-stream; 
	name="christer.holmberg.vcf"
Content-Disposition: attachment; filename="christer.holmberg.vcf"
Content-Transfer-Encoding: base64

YmVnaW46dmNhcmQgDQpuOkhvbG1iZXJnO0NocmlzdGVyDQp0ZWw7Y2VsbDorMzU4LTQwLTU2MDQ0
MTINCnRlbDt3b3JrOiszNTgtOS0yOTkyOTQzDQp4LW1vemlsbGEtaHRtbDpGQUxTRQ0Kb3JnOkVy
aWNzc29uO0lQIE11bHRpbWVkaWEgLyBBZHZhbmNlZCBTaWduYWxsaW5nIFJlc2VhcmNoIExhYm9y
YXRvcnkNCmFkcjo7Ozs7OzsNCnZlcnNpb246Mi4xDQplbWFpbDtpbnRlcm5ldDpjaHJpc3Rlci5o
b2xtYmVyZ0BsbWYuZXJpY3Nzb24uc2UNCnRpdGxlOlN5c3RlbSBEZXNpZ25lcg0KZm46Q2hyaXN0
ZXIgSG9sbWJlcmcNCmVuZDp2Y2FyZA0KDQo=

--0__=te14iDPNZKH2CM9vaPShphOXAtxVappiaHVLtVzdnm5s1zCOyhl9pDg6--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 06:07:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12906
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 06:07:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 848C34434E; Wed, 10 Jan 2001 05:08:03 -0500 (EST)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id 045874433E
	for <sip@share.research.bell-labs.com>; Wed, 10 Jan 2001 05:07:27 -0500 (EST)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jan 10 06:04:48 EST 2001
Received: by lists.bell-labs.com (Postfix)
	id C6C0944380; Wed, 10 Jan 2001 05:52:53 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from uk0006exch001h.wins.lucent.com (uk0006exch001h.uk.lucent.com [135.86.160.150])
	by lists.bell-labs.com (Postfix) with ESMTP id DF0404437D
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 05:52:52 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21)
	id <Y067MH2W>; Wed, 10 Jan 2001 10:52:28 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB00BD08A@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: Sean Olson <sean.olson@ericsson.com>,
        Robert Sparks <rsparks@dynamicsoft.com>,
        "'Rohan Mahy'" <rohan@cisco.com>
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] REFER progress
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 10:52:24 -0000

I was unsure on whether to throw this in on the SUBSCRIBE/NOTIFY discussion
or on the REFER discussion.

If I can go back to some of the early ISDN discussions (groans no doubt all
round) and come up with some of the requirements that went into the ISDN
Notification indicator, then those requirements identified a need for
something that 

-	was to be sent to the end user
-	did not need to be understood along the way
-	was not critical to the end terminal (i.e. could be thrown away if
not required).

The ISDN version could have ended up better, but does the above give some
starting point to writing down some requirements in this area, and then
deciding on a single generic mechanism, rather than ending up with different
things in separate drafts. So rephrasing in SIP speak

-	need a means for a proxy or remote UA to send information to the
other UA.
-	intervening proxies on the path do not need to be able to understand
any of the contents, and will simply pass on the contents without
modification.
(Discussion point - is there a need to include user identification in such
information that needs to be subject to the privacy draft)
-	a receiving UA does not need to understand the contents; if they are
not understood, then the information is discarded.
-	the information could consist of multiple parameters.
-	needs to be able to be included with other SIP request response
flows, or in a request of its own.
-	may be in association with an existing session, or may be
independent of a session.

I would also not that if we came up with a mechanism that fulfilled these
requirements (and I get the impression that an Event header used in extended
circumstances, with NOTIFY as a carriage mechanism where no other request
exists, would do that), then some of the requirements of the
diversion/forwarding draft could also be met by it, e.g. the need to inform
the calling and forwarded-to users that forwarding has taken place.

Ready to duck.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com

> ----------
> From: 	Rohan Mahy[SMTP:rohan@cisco.com]
> Sent: 	09 January 2001 18:49
> To: 	Sean Olson; Robert Sparks
> Cc: 	sip@lists.bell-labs.com
> Subject: 	Re: [SIP] REFER progress
> 
> Hi,
> 
> I agree with Sean that an implicit NOTIFY is straightforward, no more
> complicated than REFERDONE and solves the timeout problem.  I hope we
> don't
> need a meeting to close this issue.  ;-)
> 
> The "other" problem, however, is the one that opened the can of worms.
> What primitive(s) do you use to get attended transfer to work?  All of the
> proposals (something like 4 of them) work and solve the requirement for an
> attended transfer.  Some of these proposals deal more with the  bis draft
> (see Tom Taylor's post today).  Everyone seems to want other features as
> well, but we need to see at least a "sketch" of the complete features
> picture associated with each proposal.  This is why I proposed the one-day
> face-to-face meeting.
> 
> thanks,
> -rohan
> 
> 
> 
> At 12:15 PM 1/9/01 , Sean Olson wrote:
> >I'm sorry, I don't see the standardization of the
> >REFERDONE as being any easier than the standardization
> >of a NOTIFY to serve the same purpose.
> >
> >To satisfy a need stated by Billy, the
> >body of the NOTIFY could simply be the SDP
> >from the 200 OK (assuming an INVITE) or empty
> >for a BYE. Uses of REFER for other methods would
> >need to be specified in extension drafts.
> >The Event: token could be "referdone".
> >
> >Is there anything else that needs to be specified
> >for the use of NOTIFY that I am missing?
> >
> >I don't wish to drag this out forever. I think
> >the solution is fairly simple and straightforward
> >and could be extended in the future.
> >
> >Please point out faults with this proposal and
> >areas of implementation difficulty.
> >/sean
> >
> >Robert Sparks wrote:
> >
> >> a.s. This got a little long - sorry
> >>      It does contain a concrete proposal.
> >> ------------
> >> I think we are falling into a set of traps
> >> with the REFER discussions, endangering an
> >> already overdue deliverable.
> >> 
> >> The worst is specification creep. The group
> >> was pretty happy with the functionality of
> >> the current draft. When we tripped up on the
> >> timeout problem, we saw a host of extra 
> >> functionality we could add while working
> >> around that problem.
> >> 
> >> Most of us have gravitated towards a model
> >> where REFER is answered with a set of
> >> reciprocal responses (essentially NOTIFYs,
> >> possibly of a different name, with or without
> >> an explicit subscribe). What we _haven't_
> >> spent much time on is the profile of those
> >> responses. How many can there be? What do
> >> they contain?
> >> 
> >> I really anticipate the answers to those last
> >> questions will vary widely depending on the
> >> application using REFER. We want to be able
> >> to do other things than transfer (this is 
> >> why the method got renamed from TRANSFER).
> >> A rich response set for a REFER that triggers
> >> a SUBSCRIBE is likely to be entirely different
> >> in character from one that triggers an INVITE.
> >> 
> >> 
> >> PROPOSAL
> >> In interests of meeting our working group
> >> deliverable on this topic (now _WAY_ overdue),
> >> I suggest that obtaining this rich response
> >> set has shown itself to be too big a bite. I
> >> propose that it is time to fall back to a single
> >> REFERDONE reciprocal request, carrying the
> >> information that is provided in the current
> >> draft's final response. This would provide a
> >> baseline version of REFER that would meet the
> >> requirements the current draft addresses.
> >> 
> >> I further propose that when we complete that work,
> >> we can return to REFER and define an extension that
> >> would get the richer response set, addressing the
> >> current lack of definition of that response set
> >> with something like sip-event profiles.
> >> 
> >> RjS
> >> 
> >> 
> >> 
> >> _______________________________________________
> >> SIP mailing list
> >> SIP@lists.bell-labs.com
> >> http://lists.bell-labs.com/mailman/listinfo/sip
> >
> >
> >_______________________________________________
> >SIP mailing list
> >SIP@lists.bell-labs.com
> >http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 06:49:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA13440
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 06:49:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B193644338; Wed, 10 Jan 2001 05:50:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id D704644337
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 05:49:05 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f0ABmld29949;
	Wed, 10 Jan 2001 12:48:48 +0100 (MET)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.64])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA09285;
	Wed, 10 Jan 2001 13:48:47 +0200 (EET)
Message-ID: <3A5C4C18.39554C0C@lmf.ericsson.se>
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Cc: Keith Robinson <Keith.Robinson@marconi.com>
Subject: Re: [SIP] Overlap Sending
References: <802569D0.003887E7.00@marconicomms.com>
Content-Type: multipart/mixed;
 boundary="------------D7B2A0BBAE193D3319844732"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 13:48:40 +0200

This is a multi-part message in MIME format.
--------------D7B2A0BBAE193D3319844732
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

>If we say that the 484 clears down the call attempt and therefore associated
>state in the preceding SIP nodes then I have no problem with generating a new initial INVITE with a new
>TO header; this seems consistent with the RFC. Note that the paragraph in section 4.2.1 starting
>"A UAS acting as a gateway.." implies that the UAS that generated the 484 does not kill associated state with
>this call attempt.
> 
>So, the problem I have with using the same Call-Id though  is
>that it is unclear from the RFC what a UAS will make of the received request.

One idea would be to write that an UAS that sends a 484 response and
KNOWS it may receive a new INVITE with more digits (a gateway, for
example) MUST accept the same Call-ID (the To header is different,
though).

>Referring to section 11.5 we get to case 3, where a request has been received with a Call-Id that matches
>a current; however case 3 only explains the meaning of the request if the To and From fields match
>stored values at this point, - "the request is a new transaction for an existing leg", it does not explain >what it means if either the From or To fields are differ.

My understanding that when we have sent the 484 we don't have an
existing leg anymore. The UAS does have an ongoing transaction, waiting
for the ACK, but since we will send a new To header in the next INVITE
we will not mess with that transaction even if the Call-ID is the same.

>Is it an update to either field ?

I think that since multiple headers are used to define a call-leg, we
have a different call-leg as soon as one of them change, even if the
other headers (including the Call-ID) remains the same.

>Is it a request for a new leg ? Is it erroneous. I have raised this
>as a seperate question on the list as it is probably a more general problem.
> 
>I think it is therefore safest for the 484 to kill that call attempt and
>associated state completely, including within the terminating UAS that generated it. INVITES carrying the >subsequent digits (plus original digits) in the TO field will  then be treated as brand new call attempts with >no ambiguity.
> 
>I am not advocating that this is the best solution, just the safest without
>significant change to the RFC.

I agree. It is the safest, but not the fastest, since the gateway will
delete any possible information it could have used for the subsequent
INVITE.
 
>As I said previously, I believe a better solution would be to able to send
>re-INVITES after an infomational response, but before the final ACK. Of course, this would mean the TO field >has to remain consistent for all these re-INVITES so could not be used to carry the subsequent digits.........

I agree. In that case I guess we would need a separate header, or a new
To header parameter, to transport the subsequent digits.

Regards,

Christer Holmberg
Ericsson Finland


>Advive on this matter from the SIP authors would be gratefully appreciated.
 
> Regards,
> 
> K. Robinson.
> 
> Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 09/01/2001 10:50:06
> 
> 
> 
> 
> 
> 
> 
>  To:      sip@lists.bell-labs.com
> 
>  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
>           <stlevy@cisco.com>
> 
> 
> 
>  Subject: Re: [SIP] Overlap Sending
> 
> 
> Hi,
> 
> >I take your point about requiring a proxy to route 6543231@sipgw.com the same
> >way as 65432@sipgw.com but I believe this to be entirely within the routing
> data
> >set up by the administration. Allowing clients to choose there own path through
> the
> >network to get to their desired destination using various digit sequences seems
> like the
> >classic way of exposing networks to fraudulent use (billing avoidance,
> bypassing security,
> >etc). However, I think this is a seperate issue.
> 
> Well, it's related :)
> 
> >I am still concerned about the Route header overwriting the R-URI and therefore
> >destroying the subsequent digits when subsequent messages are routed using the
> Route header mechanism. I
> >am not sure that putting the subsequent digits in the TO header helps because I
> believe the TO
> >URL is supposed to be invariant during the lifetime of the call leg.
> 
> Well, this depends a little on how you define a call leg, I guess...
> Since you got a 4xx response to your first INVITE, you didn't manage to
> set up a call leg, so then you try to set up a "new" call leg - with a
> new R-URI and To header...
> 
> INVITE 123@sipgw.com
> To: 123@sipgw.com
> 
> <---- 484 -----
> 
> INVITE 123456@sipgw.com
> To: 123456@sipgw.com
> 
> >Modifying the TO URL after the initial INVITE I think will cause problems for
> proxies  that are using the TO >URL to match subsequent requests to call legs in
> progress.
> 
> Since the proxy sent back 484, I wouldn't consider the call leg to be in
> progress anymore (after the proxy receive the ACK, that is).
> 
> And, the proxy will probably have to do the routing based on the To
> header, since the R-URI will probably (unless we use an outbound proxy)
> be the address of the proxy itself, so if the To header isn't changed
> the proxy will try to route 123@sipgw.com every time, even if more
> digits have provided by the client. And, if the proxy is supposed to
> "combine" the Current-Dial-String header value with the To header, to be
> able to route, I think that the client could put the new value in the To
> header from the beginning. Because, if the proxy doesn't support the
> Current-Dial-String it wouldn't be able to do anything, since both the
> R-URI and To header could be the same in the subsequent INVITEs. If you
> have a updated To header, and the proxy doesn't support the digitmap, it
> would at least be able to route the new To header - even if the message
> may take a "wrong" route.
> 
> >Without introducing a new header to carry the digit string, then I think the
> >only other way to make overlap sending work is for the 484 to clear down the
> call leg as other 4XX
> >responses do and subsequent INVITES with the original digits + additional
> digits to be a new INVITE (with a
> >new Call-Id).
> 
> I agree, but I don't think it requires a new Call-Id. Then we could
> still define a digitmap header to make sure  (if it is supported by the
> proxy) that the proxy will always route the message correctly, no matter
> how many INVITEs you need to provide all digits.
> 
> >The initial INVITE will not be routed using Route headers, so the digit string
> in the R-URI will
> >not be lost.
> 
> Proxies may change the R-URI...
> 
> >There still could be a problem if the client has built a Route header (learnt
> out-of-band) and puts
> >this in the initial INVITE; the same problem may occur.
> 
> This will not be a problem if all servers in the path support the
> digitmap... :)
> 
> >Without clarification of this matter in the bis draft then I don't think
> overlap
> >sending is going to be interoperable.
> 
> I agree.
> 
> Personally I think (no, this is NOT a proposal to re-write SIP :) the
> best way would be to have some kind of "multi-message" setup, and that
> would also solve a number of other issues (i.e. ISUP transparency).
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> Keith Robinson wrote:
> >
> > Let's consider the following point:
> >
> > "I don't know. I haven't seen a proxy that would route depending on the
> > user, but it COULD happend. Let's assume , for example, that you do a
> > SRV DNS lookup, and get a list of servers. Then you MAY choose a
> > different server, for load balance purpose e.g., depending on the user
> > name. Just an example..."
> >
> > One way of ensuring that subsequent requests always traverse a given SIP
> > node is for that node to Record-Route or supply a Contact ; it is likely that
> > proxies and
> > UAS at PSTN interworking points will require to stay in the signalling path
> > during
> > call setup so will do so.  Now, suppose one such node receives an initial
> INVITE
> > with
> > a R-URI of sip:654@sipgw.com and creates a Contact header thus:
> >
> > Contact: sip:654@sipgw.com;maddr=sipgw.com
> >
> > This is then returned in the 484 response so that the sending UA may build a
> > Route header from it. Here is my first concern; will the sending UA treat the
> > subsequent INVITE as a subsequent INVITE or as a new INVITE on a new
> > Call-Id ? I ask because the 484 response is non-200 final response which
> > implies that that call attempt has failed; obviously in this case it hasn't
> > failed
> > (not yet, anyway) its just been partially set up.  Does this lead to special
> > case handling
> > for a particular 4XX response ? In fact, the 484 is almost like an
> informational
> > response.
> > Would it be better to send an informational response (say 183) and the spec
> > updated to
> > allow subsequent INVITEs to be sent before the final ACK (a point raised by J.
> > Rosenberg
> > earlier on the list, but in a different context - to convey updated SDP
> > information).
> >
> > Assuming the above is resolved one way or another, then a SIP node preceding
> > sipgw.com is going to receive a subsequent INVITE for this call (containing
> > additional
> > digits 321)  that will look something like:
> >
> > INVITE sip:321@preceding.sipgw.com
> > Route: sip:654@sipgw.com;maddr=sipgw.com
> >
> > As a Route header is present, this will be used to route the INVITE so
> > therefore sipgw.com will receive an INVITE with the following Request
> > Line:
> >
> > INVITE sip:654@sipgw.com;maddr=sipgw.com
> >
> > And here is a more worrying problem, the subsequent digits have been lost.
> > The situation would be no better if the subsequent INVITE contained original
> > digits
> > plus subsequent digits; they would still be lost.
> >
> > The problem stems from the fact that the R-URI is supposed to be invariant at
> > each
> > node during the lifetime of the call leg, yet to do overlap sending it is
> being
> > used to
> > convey new information so therefore does not remain invariant and other parts
> of
> > the
> > protocol which assume it is invariant e.g., routing using the Route header
> > break.
> >
> > Using a TEL URL does not help either; the digits would still be lost after the
> > popping of
> > the Route entry into the R-URI.
> >
> > It would be easier to implement overlap sending if a seperate header could be
> > used to
> > convey the dialled digits, so an original INVITE may look something like:
> >
> > INVITE sip:digitdecode@sipgw.com
> > Current-Dial-String: 01623
> >
> > The subsequent INVITES would then look something like:
> >
> > INVITE sip:digitdecode@sipgw.com;maddr=sipgw.com
> > Current-Dial-String: 01623654398
> >
> > This ties in with your point of implementing a digit map header.
> >
> > Regards,
> >
> > K. Robinson.
> >
> > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 13:40:47
> >
> >
> >
> >
> >
> >
> >
> >  To:      sip@lists.bell-labs.com
> >
> >  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
> >           <stlevy@cisco.com>
> >
> >
> >
> >  Subject: Re: [SIP] Overlap Sending
> >
> >
> > Hi,
> >
> > >If a proxy, not serving uas.com, receives an INVITE with a R-URI of
> 4@uas.com,
> > >why would it route it differently (Route headers not withstanding) from an
> > INVITE
> > >with a R-URI of 441@uas.com ?
> >
> > I don't know. I haven't seen a proxy that would route depending on the
> > user, but it COULD happend. Let's assume , for example, that you do a
> > SRV DNS lookup, and get a list of servers. Then you MAY choose a
> > different server, for load balance purpose e.g., depending on the user
> > name. Just an example...
> >
> > And, what happen if you use a TEL-URL, where you have to route depending
> > on the user name (=telephone number). I guess using a ENUM DNS lookup
> > COULD route it to the same host, but then I guess you would have to
> > configure your DNS to for all the possible combinations (4.e164.arpa,
> > 44.e164.arpa and 441.e164.arpa)...
> >
> > >Surely, if the proxy does not serve the domain identified in the R-URI it
> > cannot
> > >make any routing decisions based on the user part of the R-URI.
> > >If, on the other hand, the proxy does serve uas.com, then it will be involved
> > in
> > >routing the call using the dialled digit string and I would expect it to know
> > such things as minimum digits to
> > >translation and perhaps even maximum number of digits to follow. Also,
> because
> > the proxy is doing digit based
> > >routing it must be subject to the requirements of overlap sending so I would
> > expect it to be stateful, at >least until call setup is complete, in which
> case
> > remembering previous call information would be reasonable. >In fact, such a
> > proxy appears much like the interworking UAs I referred to previously and to
> > which my question >applies.
> >
> > That was my point - that you also have to have support for this in your
> > proxies, and not only in your client.
> >
> > I think the issue is that there are lots of what-ifs involved in this,
> > and it should be specified how the specific cases are handled -
> > especially by proxies and redirect servers.
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> > > Regards,
> > >
> > > K. Robinson
> > >
> > > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > Keith Robinson wrote:
> > >
> > > If a proxy, not serving uas.com, receives an INVITE with a R-URI of
> 4@uas.com,
> > > why
> > > would it route it differently (Route headers not withstanding) from an
> INVITE
> > > with a R-URI of 441@uas.com ?
> > > Surely, if the proxy does not serve the domain identified in the R-URI it
> > cannot
> > > make any
> > > routing decisions based on the user part of the R-URI.
> > >
> > > If, on the other hand, the proxy does serve uas.com, then it will be
> involved
> > in
> > > routing the call using the dialled
> > > digit string and I would expect it to know such things as minimum digits to
> > > translation and perhaps even
> > > maximum number of digits to follow. Also, because the proxy is doing digit
> > based
> > > routing it must be subject to the
> > > requirements of overlap sending so I would expect it to be stateful, at
> least
> > > until call setup is complete, in which
> > > case remembering previous call information would be reasonable. In fact,
> such
> > a
> > > proxy appears much like the
> > > interworking UAs I referred to previously and to which my question applies.
> > >
> > > Regards,
> > >
> > > K. Robinson
> > >
> > > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  To:      sip@lists.bell-labs.com
> > >
> > >  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
> > >           <stlevy@cisco.com>
> > >
> > >
> > >
> > >  Subject: Re: [SIP] Overlap Sending
> > >
> > >
> > > Hi,
> > >
> > > I think sending re-INVITES containing only subsequent digits will create
> > > some problems. It's not enough that the UAS remembers the previous
> > > INVITEs for the specific Call-ID, you may also have intermediate
> > > redirect- and/or proxy servers that make their redirect/forwarding
> > > decissions based on the destination number, and then they would also
> > > have to remember the previous INVITEs, and they would possible also have
> > > to be able to know if, and in some cases, how many digits will follow
> > > (e.g. 4@uas.com may be routed to a complete destination than
> > > 441@uas.com, etc.) Maybe we should implement some kind of digit-map
> > > header, or something... :)
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > > Keith Robinson wrote:
> > > >
> > > > Yes, this is the type of case I have in mind. The question I have is what
> > are
> > > > the subsequent INVITES; are they
> > > >
> > > > a) New INVITES, on a new Call-Id containing the original digits (from
> > original
> > > > INVITE) + subsequent digits ?
> > > >
> > > > or
> > > >
> > > > b) re-INVITES containing only subsequent digits ?
> > > >
> > > > or
> > > >
> > > > c) re-INVITES containing original digits + subsequent digits ?
> > > >
> > > > The sending UAs I referred to in my previous note are those that sit in
> > > PSTN/SIP
> > > > gateways,
> > > > not necessarily an originating UA sitting on someones desktop.
> > > >
> > > > So, the question applies as much to these interworking UAs for
> constructing
> > > > the subsequent INVITEs as well as to receiving UAs for interpreting them.
> > > >
> > > > Regards,
> > > >
> > > > K. Robinson.
> > > >
> > > > Steve Levy <stlevy@cisco.com> on 05/01/2001 22:32:00
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >  To:      Keith Robinson/MAIN/MC1@MCMAIN,
> > > >           sip@lists.bell-labs.com
> > > >
> > > >  cc:
> > > >
> > > >
> > > >
> > > >  Subject: Re: [SIP] Overlap Sending
> > > >
> > > >
> > > > Hi Keith,
> > > >
> > > > I was wondering if in considering overlap sending issues and SIP if you
> were
> > > > considering the case of overlap sending across multiple networks with
> > variable
> > > > length digits.
> > > >
> > > > In this case, in order to avoid post dial delay, the digits need to be
> > passed
> > > > through the networks to the final destiantion network prior to end of dial
> > > > (since the destination network is the only network that knows how many
> > digits
> > > > are required). So in effect there may be additional digits sent after an
> > > INVITE
> > > > has been received and sent downstream to the callee.
> > > >
> > > > Thanks,
> > > > Steve
> > > >
> > > > At 03:50 PM 1/5/01 +0000, Keith Robinson wrote:
> > > > >
> > > > >
> > > > >I have the following query regarding overlap sending as defined in
> > > > >rfc2543bis-02:
> > > > >
> > > > >Section 4.2.1 states the following:
> > > > >
> > > > >"...the UAS compares the Request-URI with Request-URI of the previous
> > INVITE
> > > > >request
> > > > >for the same Call-Id. If the Request-URI  contains additional digits in
> the
> > > > >'user' part, the UAS
> > > > >treats the INVITE as adding additional digits to the original dialed
> > string."
> > > > >
> > > > >This appears to imply that the subsequent INVITE contains the original
> > > dialled
> > > > >string plus the
> > > > >additional digits; if this is the case, then there is no need for the UAS
> > to
> > > > >remember the
> > > > >previous string, and therefore no need to keep any state regarding the
> > > previous
> > > > >attempt.
> > > > >The subsequent INVITE can really be a new INVITE., i.e. a new Call-Id.
> > > > >
> > > > >If, on the other hand, the sending UA only sends additional digits, then
> > the
> > > > >original digits
> > > > >will have to be remembered by the UAS, and the INVITE matched up with
> this
> > > > >state
> > > > >so
> > > > >this INVITE must be on the same Call-Id.
> > > > >
> > > > >This latter case is similar to the way existing telephony protocols
> > transmit
> > > > >addtional digits
> > > > >when doing overlap sending.
> > > > >
> > > > >So, upon receiving a response of 484 Address Incomplete, does the sending
> > UA
> > > > >send
> > > > >original digits plus aditional digits on a new Call-Id or additional
> digits
> > > > >only
> > > > >on the same
> > > > >Call-Id with an incremented Cseq.
> > > > >
> > > > >Regards,
> > > > >
> > > > >K. Robinson.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >_______________________________________________
> > > > >SIP mailing list
> > > > >SIP@lists.bell-labs.com
> > > > >http://lists.bell-labs.com/mailman/listinfo/sip
> > > >
> > > > _______________________________________________
> > > > SIP mailing list
> > > > SIP@lists.bell-labs.com
> > > > http://lists.bell-labs.com/mailman/listinfo/sip
> > > >
> > > > _______________________________________________
> > > > SIP mailing list
> > > > SIP@lists.bell-labs.com
> > > > http://lists.bell-labs.com/mailman/listinfo/sip
--------------D7B2A0BBAE193D3319844732
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------D7B2A0BBAE193D3319844732--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 08:16:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15672
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 08:16:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3E20644338; Wed, 10 Jan 2001 07:17:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web10307.mail.yahoo.com (web10307.mail.yahoo.com [216.136.130.85])
	by lists.bell-labs.com (Postfix) with SMTP id C5B6944337
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 07:16:08 -0500 (EST)
Message-ID: <20010110131556.67815.qmail@web10307.mail.yahoo.com>
Received: from [203.200.4.17] by web10307.mail.yahoo.com; Wed, 10 Jan 2001 05:15:56 PST
From: james jack <sipjames@yahoo.com>
To: sip@lists.bell-labs.com
Cc: schulzrinne@cs.columbia.edu, schooler@cs.caltech.edu,
        jdrosen@dynamicsoft.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] Consultation on  the third party Control!!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 05:15:56 -0800 (PST)

Dear All:
   I have one question to consult, the situation is
lsited as the following:
   If SIP UA A has already installed connection with 
SIP UA B, now UA want to UA B to send INVITE to UA C,
User A can send a INVITE to B with C in also header.
This is a solution.
   Now I have one doubt, will also header out of date,
that is, Will also header will be widely accepted by
SIP extension?
   It would be very appreciate for you to give me some
ideas!
   Best Regards!
                       Yours: James

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 09:04:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16872
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 09:04:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5FEB444338; Wed, 10 Jan 2001 08:05:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by lists.bell-labs.com (Postfix) with ESMTP id 7E09744337
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 08:04:51 -0500 (EST)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA23665 for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 07:04:38 -0700 (MST)]
Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id HAA04315 for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 07:01:03 -0700 (MST)]
Received: from email.mot.com (pcwks120.miel.mot.com [217.1.129.146])
	by miel.mot.com (8.9.3/8.9.3) with ESMTP id TAA08958;
	Wed, 10 Jan 2001 19:40:19 +0530 (IST)
Message-ID: <3A5C6DB9.B718B644@email.mot.com>
From: Gaurav Taneja <A15835@email.mot.com>
Organization: Motorola India Electronics Ltd.
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: SIP WG Mailing List <sip@lists.bell-labs.com>
Cc: Gaurav <Gaurav_Taneja-A15835@email.mot.com>
Content-Type: multipart/mixed;
 boundary="------------06685FFEC77EC54A4A0DC527"
Subject: [SIP] RFC 2543 - SIP Protocol Properties
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 19:42:09 +0530

This is a multi-part message in MIME format.
--------------06685FFEC77EC54A4A0DC527
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

This is with reference to RFC 2543 (March 1999), page 19, section 1.5.2
"Lower-Layer-Protocol Neutral" . The last line in para. 2 states that
"TCP allows easier passage through existing firewalls".  Could someone
elaborate on how TCP supports this?

-Gaurav





--------------06685FFEC77EC54A4A0DC527
Content-Type: text/x-vcard; charset=us-ascii;
 name="A15835.vcf"
Content-Description: Card for Gaurav Taneja
Content-Disposition: attachment;
 filename="A15835.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Taneja;Gaurav
tel;cell:+91 9845149512
tel;fax:+91 80 5598660
tel;work:+91 80 5598615 (x:2145)
x-mozilla-html:TRUE
org:Motorola India Electronics Ltd.;Wireless Software Solutions
version:2.1
email;internet:gauravt@miel.mot.com
title:Lead Engineer (R&D)
adr;quoted-printable:;;Motorola India Electronics Ltd.=0D=0A'The Senate', 33-A, Ulsoor Road=0D=0ABangalore-42, India;Bangalore;Karnataka;560 042;India
fn:Gaurav Taneja
end:vcard

--------------06685FFEC77EC54A4A0DC527--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 11:01:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19975
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 11:01:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C26F744337; Wed, 10 Jan 2001 10:02:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 8C7B544336
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 10:01:05 -0500 (EST)
Received: from CINQUECENTO ([63.110.3.212])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id LAA02857;
	Wed, 10 Jan 2001 11:03:39 -0500 (EST)
From: "Robert Sparks" <rsparks@dynamicsoft.com>
To: "'Rick Dean'" <siplist@fdd.com>, <sip@lists.bell-labs.com>
Subject: RE: [SIP] REFER progress
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30474BB@DYN-TX-EXCH-001.dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <20010109180745.B16839@fdd.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 09:09:27 -0600
Content-Transfer-Encoding: 7bit

> Sean,
I'm not Sean, but I'll take a stab at one of these.

> 
> Does the REFERDONE/NOTIFY sender have to wait for the
> REFERDONE/NOTIFY to complete before he sends a
> re-INVITE/BYE?  I have been trying hard not to have 
> a message queue.

Why would it have to? If the application doesn't really
care about the final response to the refer, it can send
the BYE (or do whatever else is appropriate at the time)
immediately. It doesn't need to keep state to respond
to the NOTIFY.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 11:04:21 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19997
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 11:04:20 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4B49444344; Wed, 10 Jan 2001 10:03:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id C1AAF44344
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 10:02:12 -0500 (EST)
Received: from CINQUECENTO ([63.110.3.212])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id LAA02861;
	Wed, 10 Jan 2001 11:03:43 -0500 (EST)
From: "Robert Sparks" <rsparks@dynamicsoft.com>
To: "'Henning Schulzrinne'" <schulzrinne@cs.columbia.edu>,
        "Alan Johnston" <alan.johnston@wcom.com>
Cc: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
        "Sean Olson" <sean.olson@ericsson.com>,
        "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        "Robert Sparks" <rsparks@dynamicsoft.com>,
        "'Tom-PT Taylor'" <taylor@nortelnetworks.com>,
        "'Rohan Mahy'" <rohan@cisco.com>, "sip" <sip@lists.bell-labs.com>
Subject: RE: [SIP] REFER progress
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F30474BC@DYN-TX-EXCH-001.dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <3A5BDB0B.28CEB745@cs.columbia.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 09:09:38 -0600
Content-Transfer-Encoding: 7bit

Ok - I think I see enough of a consensus trend to take this and produce
a revised draft.

I will use the idea of an implicit subscribe and  a _single_ NOTIFY to
the Event: refer-done. We can deal with other Event:s in subsequent work.

To mitigate risk, please try to take Rick's thread to completion quickly.

RjS



> -----Original Message-----
> From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu]
> Sent: Tuesday, January 09, 2001 9:46 PM
> To: Alan Johnston
> Cc: Henning G. Schulzrinne; Sean Olson; Fairlie-Cuninghame, Robert;
> 'Robert Sparks'; 'Tom-PT Taylor'; 'Rohan Mahy'; sip
> Subject: Re: [SIP] REFER progress
> 
> 
> 
> 
> Alan Johnston wrote:
> > 
> > I'd be OK with REFER generating an implicit NOTIFY response 
> (instead of
> > REFERDONE) as long as:
> > 
> > 1. This usage of NOTIFY is defined in a document separate 
> from the other
> > presence stuff (maybe even part of the REFER document).  
> Our PSTN Gateways
> > will never implement full presence, but we will want them 
> to support various
> > types of call transfers using REFER.  Writing requirements 
> for vendors that
> > say "implement only this piece of this document" is problematic.
> 
> This is similar to the other uses of NOTIFY outside presence, such as
> the vmail notification and some of the suggested uses in 
> connection with
> conferences. I can't see much that needs to be said generically, since
> NOTIFY is just another method. (Most of the discussion in the
> presence/events documents seems to be about SUBSCRIBE, with NOTIFY
> receiving relatively little coverage.) Thus, beyond saying a sentence
> about Call-IDs, this should all be contained in the REFER draft.
> 
> > 
> > 2. There are separate event for the progress of the REFERed 
> Request (18x
> > response received) vs. completion of the REFERed Request 
> (final response -
> > 2xx or failure).  This way, we can implement all the 
> different types of call
> > transfers in the PSTN, completely blind transfers, 
> transfers where you
> > disconnect after the target phone rings, and fully attended 
> transfer where
> > you only disconnect after a successful completion of the 
> transfer.  I'm not
> > necessarily in favor of multiple NOTIFY per REFER, just 
> that the REFER
> > should be able to specify which call progress or completion 
> event will
> > generate the one and only NOTIFY.
> 
> Agreed. It would be easy enough to specify multiple Event labels and
> this would be consistent, I believe, with the overall event
> architecture. If desired, details can then be encoded as 
> message/sip, as
> suggested earlier.
> 


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 11:07:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20119
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 11:07:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A8B8E4434E; Wed, 10 Jan 2001 10:08:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 44AB844344
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 10:07:53 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA29302;
	Wed, 10 Jan 2001 11:07:40 -0500 (EST)
Message-ID: <3A5C88CC.7C66CF9E@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Sparks <rsparks@dynamicsoft.com>
Cc: "'Rick Dean'" <siplist@fdd.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] REFER progress
References: <9BF66EBF6BEFD942915B4D4D45C051F30474BB@DYN-TX-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 11:07:40 -0500
Content-Transfer-Encoding: 7bit

Robert Sparks wrote:
> 
> > Sean,
> I'm not Sean, but I'll take a stab at one of these.
> 
> >
> > Does the REFERDONE/NOTIFY sender have to wait for the
> > REFERDONE/NOTIFY to complete before he sends a
> > re-INVITE/BYE?  I have been trying hard not to have
> > a message queue.
> 
> Why would it have to? If the application doesn't really
> care about the final response to the refer, it can send
> the BYE (or do whatever else is appropriate at the time)
> immediately. It doesn't need to keep state to respond
> to the NOTIFY.

I don't see why a system that doesn't care about the NOTIFY needs to
keep state. Just treat it like any other unsolicited request, with a 200
if you want to be charitable or 481 or whatever the events draft
specifies (or should...).

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 12:56:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22462
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 12:56:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A844144337; Wed, 10 Jan 2001 11:57:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from calum.csclub.uwaterloo.ca (calum.csclub.uwaterloo.ca [129.97.134.11])
	by lists.bell-labs.com (Postfix) with ESMTP id CEA0944336
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 11:56:02 -0500 (EST)
Received: (from wbiggs@localhost)
	by calum.csclub.uwaterloo.ca (8.9.3+Sun/8.9.3) id NAA12724;
	Wed, 10 Jan 2001 13:00:56 -0500 (EST)
From: Billy Biggs <billy@billybiggs.com>
To: Rick Dean <siplist@fdd.com>
Cc: Sip List <sip@lists.bell-labs.com>
Subject: Re: [SIP] REFER progress
Message-ID: <20010110130054.B12449@csclub.uwaterloo.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 13:00:55 -0500

  Maybe I can better explain the issue:

  Say we use REFER to negotiate transfer, and the transfer fails.  Rick
wants the REFER receiver to send a re-INVITE back to the REFER sender to
re-negotiate the session, not a NOTIFY.  Reasons:

  1. The code on the INVITE receiver can be reused.  The REFER sender
     sends a 180 Ringing until the user answers the line.  The INVITE
     sending phone correctly plays local ringback.

  2. How does the NOTIFY sender know to play local ringing?  Send a 180
     response to the NOTIFY?  Should we play ringing in the RTP?

  3. The INVITE transaction can take a long time.  NOTIFY can't, meaning
     we can't send 180s to the NOTIFY otherwise we get the same problem
     we had with REFER.

  As a compromise, I suggested that the NOTIFY and the REFER allow SDP
bodies so that at least we could avoid message queues for re-negotiation
of the session.  This way, we can at least send the ringing as audio in
an RTP session, and negotiate this session without having a message
queue (send NOTIFY then send re-INVITE).  To optimize a successful
transfer case, I want to allow a BYE to mean that no NOTIFY will be sent
(to avoid send NOTIFY then send BYE).

  I understand the desire for a primitive, but please try to think about
how to design transfer using REFER.   Especially the flow for a failed
transfer.  How does each actor know what to do?  How should the ringing
sound be sent as you ring back the REFER sender?  If using REFER to
is too difficult, then the primitive is wrong.  One problem we have here
is that most of the people arguing about the NOTIFY stuff aren't trying
to design a phone.

-- 
Billy Biggs
wbiggs@csclub.uwaterloo.ca

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 13:14:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22967
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 13:14:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 899A04434C; Wed, 10 Jan 2001 12:15:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7])
	by lists.bell-labs.com (Postfix) with ESMTP id 2EB1944341
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 12:14:40 -0500 (EST)
Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204])
	by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id SAA07497
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 18:14:28 GMT
From: Jin-Gen.Wang@Level3.com
Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1])
	by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id SAA28388
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 18:14:27 GMT
Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21)
	id <CFJHLZ0T>; Wed, 10 Jan 2001 11:16:32 -0700
Message-ID: <350829A9DA9FD411841200508BF9F0600C617A@n0217idc1.oss.level3.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] questions on stateless vs. stateful proxy
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 11:15:53 -0700

Hi, 

I have two questions on the concept of stateless vs stateful proxy. Based on
my reading of RFC2543bis-02 and FAQ on www.cs.columbia.edu, state in
stateful/stateless proxy refers to a transaction state. A call can consist
of multiple SIP transactions. So, 

(1) A stateful vs stateless proxy should be understood on a transaction by
transaction basis. Am I correct?
(2) A physical proxy can act as a stateful proxy for some transactions
within a call, and as a stateless proxy for some other transactions within
the same call. Am I correct? (Quota from FAQ: "These are also logical
entities; a physical proxy is likely to act as a stateless proxy for some
calls, stateful for others, and as a redirect server for even others." Here
it only mentions calls instead of transactions.)
Thanks in advance.

Jin-Gen Wang
Level 3 Communications, Inc.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 14:38:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25360
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 14:38:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B9A344433F; Wed, 10 Jan 2001 13:39:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 1003F44336
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 13:38:04 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0AJbnu23851;
	Wed, 10 Jan 2001 13:37:49 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: Robert Sparks <rsparks@dynamicsoft.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] REFER progress
Message-ID: <20010110133749.A22473@fdd.com>
References: <20010109180745.B16839@fdd.com> <9BF66EBF6BEFD942915B4D4D45C051F30474BB@DYN-TX-EXCH-001.dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F30474BB@DYN-TX-EXCH-001.dynamicsoft.com>; from rsparks@dynamicsoft.com on Wed, Jan 10, 2001 at 09:09:27AM -0600
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 13:37:49 -0600


On Wed, Jan 10, 2001 at 09:09:27AM -0600, Robert Sparks wrote:
> > Sean,
> I'm not Sean, but I'll take a stab at one of these.
> 
> > 
> > Does the REFERDONE/NOTIFY sender have to wait for the
> > REFERDONE/NOTIFY to complete before he sends a
> > re-INVITE/BYE?  I have been trying hard not to have 
> > a message queue.
> 
> Why would it have to? If the application doesn't really
> care about the final response to the refer, it can send
> the BYE (or do whatever else is appropriate at the time)
> immediately. It doesn't need to keep state to respond
> to the NOTIFY.
> 

My REFER sender does care if the blind transfer fails.  
Of the errors, this one will be most common.

Billy makes an excellent point about the timeout
constraints of a NOTIFY with SDP.  Quite frankly,
treating a NOTIFY like a re-INVITE is ugly in
the code, and a suprising use case.  

My proposal is very simple:  The Event:
can come in any method.  

Please suggest in the draft that if the transferee
wants to re-establish a session, he should
send it in a INVITE.  I am sure it will be popular
with the implementors.  

Protocols must be chosen by which one handles
the error cases best.  

--
Rick



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 15:25:05 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26198
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 15:25:04 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DEF0644337; Wed, 10 Jan 2001 14:25:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 4A29644336
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 14:24:21 -0500 (EST)
Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0AKO6K07559;
	Wed, 10 Jan 2001 14:24:06 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f0AKO6D13458;
	Wed, 10 Jan 2001 14:24:06 -0600 (CST)
Received: from ericsson.com (pc050184.exu.ericsson.se [138.85.50.184]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA27686; Wed, 10 Jan 2001 14:24:05 -0600 (CST)
Message-ID: <3A5CC4D8.9050504@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Billy Biggs <billy@billybiggs.com>
Cc: Rick Dean <siplist@fdd.com>, Sip List <sip@lists.bell-labs.com>
Subject: Re: [SIP] REFER progress
References: <20010110130054.B12449@csclub.uwaterloo.ca>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 14:23:52 -0600
Content-Transfer-Encoding: 7bit

Allow me to clarify a few things :)

Billy Biggs wrote:

>   Maybe I can better explain the issue:
> 
>   Say we use REFER to negotiate transfer, and the transfer fails.  Rick
> wants the REFER receiver to send a re-INVITE back to the REFER sender to
> re-negotiate the session, not a NOTIFY.  Reasons:

I never, ever, intended the NOTIFY to be used to re-negotiate
the session. Session negotiation is what INVITE does.
NOTIFY was meant as an indication which a service could use
to determine the success or failure of the REFER. That is all.
Re-negotiation of the session would happen subsequently or
perhaps independently of the NOTIFY.

> 
>   1. The code on the INVITE receiver can be reused.  The REFER sender
>      sends a 180 Ringing until the user answers the line.  The INVITE
>      sending phone correctly plays local ringback.

       I can't imagine what you are trying to do here.
       Why does the REFER sender have to worry about ringing
       at the transferee? Why isn't this left to a "180 Ringing"
       or otherwise that is received from the transfer target?
       It seems like you are looking for device control here and
       I don't think SIP is good at that.

> 
>   2. How does the NOTIFY sender know to play local ringing?  Send a 180
>      response to the NOTIFY?  Should we play ringing in the RTP?

       Why does the NOTIFY sender need to play local ringing?
       You are just using an existing session to the REFER sender
       right? i.e. there is no SIP signalling needed here. The
       NOTIFY is just a nicety.

> 
>   3. The INVITE transaction can take a long time.  NOTIFY can't, meaning
>      we can't send 180s to the NOTIFY otherwise we get the same problem
>      we had with REFER.
>

       Agreed. This is a very poor use of NOTIFY.

>   As a compromise, I suggested that the NOTIFY and the REFER allow SDP
> bodies so that at least we could avoid message queues for re-negotiation
> of the session.  This way, we can at least send the ringing as audio in
> an RTP session, and negotiate this session without having a message
> queue (send NOTIFY then send re-INVITE).  To optimize a successful
> transfer case, I want to allow a BYE to mean that no NOTIFY will be sent
> (to avoid send NOTIFY then send BYE).

I think that the problems you are encountering are because
of the interdependency of the INVITE/REFER. For this
particular case (blind transfer with "automatic" session
re-negotiation upon failure), I would recommend the following:

1) The transferor sends a REFER without a Refer-Notify:
    header indicating that the transferor doesn't care to
    receive a NOTIFY at all. The transferee immediately
    responds with a 200 OK to the REFER.

2) The transferor immediately sends a BYE. At this point
    the transferor is completely removed from the situation.

3) The transferee sends an INVITE to the transfer target.

4) The INVITE fails for whatever reason ...

5) The transferee sends a new INVITE to the transferor.
    This is a brand new session.

6) Repeat as necessary ...

With this message sequence the roles of all the actors at each
point in the call is well defined. No real magic needed. Granted,
this probably not what you had in mind -- you wanted the transferor
to remain on "hold" while the REFER was being handled. I don't
see any great advantage to this.

However, if you really want this then:

1) The transferor sends a REFER without a Refer-Notify:
    header indicating that the transferor doesn't care to
    receive a NOTIFY at all. The transferee immediately
    responds with a 200 OK to the REFER.

2) The transferor "switches to a new line". No SIP
    signalling needed here. You could, optionally, actually
    place the transferor on hold here if needed.
    The transferee sends an INVITE to the transfer target

3) The INVITE fails for some reason ...
    (If the INVITE did not fail, then the transferee could
     simply send a BYE to the transferor)

4) The transferee switches back to the original line
    (No SIP signalling involved). There is no ringing to
    worry about, etc. This is based on the concept that there
    is an actual human user at the transferor UA.

This seems a little too obvious. I must be missing a fundamental
requirement/feature of the service you are trying to build.

> 
> I understand the desire for a primitive, but please try to think about
> how to design transfer using REFER.   Especially the flow for a failed
> transfer.  How does each actor know what to do?  How should the ringing
> sound be sent as you ring back the REFER sender?  If using REFER to
> is too difficult, then the primitive is wrong.  One problem we have here
> is that most of the people arguing about the NOTIFY stuff aren't trying
> to design a phone.

On the contrary, my arguments for NOTIFY are based entirely on
the endpoints perspective. I may not be designing a phone,
but I am aware that we need phones to make this whole thing
useful :)

/sean


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 15:49:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26533
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 15:49:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D556744339; Wed, 10 Jan 2001 14:50:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from is1-55.antd.nist.gov (is1-50.antd.nist.gov [129.6.50.251])
	by lists.bell-labs.com (Postfix) with ESMTP id B7A0944337
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 14:49:36 -0500 (EST)
Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9])
	by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id PAA12195;
	Wed, 10 Jan 2001 15:43:51 -0500 (EST)
Message-ID: <3A5CCAD3.CA34E07C@nist.gov>
From: "M. Ranganathan" <mranga@nist.gov>
Reply-To: mranga@nist.gov
Organization: NIST advanced networking technologies group
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=iso-8859-1
Subject: [SIP] Syntax for To: and From: An ambiguity ?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 15:49:23 -0500
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id PAA26533

Hello!

In the syntax for FROM and TO headers, there appears to be an ambiguity.
According to what I read,

To:  sip:user@company.com;tag=9

is valid but then  is the tag a url parameter or  part of the To
header?  The ambiguity can be resolved  of course  by only allowing the
name-addr form of the address  i.e.

To: <sip:user@company.com>; tag = 9

however, the RFC does not appear to require this. Am I missing something
here?

Thanks

Ranga.

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932


ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÒ ùšŠX§‚X¬µ"þX¬¶ÏÛzYÿ•¦ìýÊ&†ÛiÿÿåŠËlý·¥—ùZnÏÜ¢oæj)fjåŠËb�ú?


From sip-admin@lists.bell-labs.com  Wed Jan 10 15:53:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26665
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 15:53:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5EE454434A; Wed, 10 Jan 2001 14:54:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by lists.bell-labs.com (Postfix) with ESMTP id B447344339
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 14:53:17 -0500 (EST)
Received: from dingdong.cisco.com (dingdong.cisco.com [161.44.3.16])
	by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA00768;
	Wed, 10 Jan 2001 15:52:52 -0500 (EST)
Received: from cisco.com ([161.44.109.7])
	by dingdong.cisco.com (Mirapoint)
	with ESMTP id AAB11898 (AUTH shbhatna);
	Wed, 10 Jan 2001 15:53:03 -0500 (EST)
Message-ID: <3A5CCBFC.954A3CE4@cisco.com>
From: Shailendra Bhatnagar <shbhatna@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: mranga@nist.gov
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Syntax for To: and From: An ambiguity ?
References: <3A5CCAD3.CA34E07C@nist.gov>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 15:54:20 -0500
Content-Transfer-Encoding: 8bit

From the SIP spec :

" The Contact, From and To header fields contain a URL. If the URL
   contains a comma, question mark or semicolon, the URL MUST be
   enclosed in angle brackets (< and >). Any URL parameters are
   contained within these brackets. If the URL is not enclosed in angle
   brackets, any semicolon-delimited parameters are header-parameters,
   not URL parameters."

Hope it helps.


"M. Ranganathan" wrote:
> 
> Hello!
> 
> In the syntax for FROM and TO headers, there appears to be an ambiguity.
> According to what I read,
> 
> To:  sip:user@company.com;tag=9
> 
> is valid but then  is the tag a url parameter or  part of the To
> header?  The ambiguity can be resolved  of course  by only allowing the
> name-addr form of the address  i.e.
> 
> To: <sip:user@company.com>; tag = 9
> 
> however, the RFC does not appear to require this. Am I missing something
> here?
> 
> Thanks
> 
> Ranga.
> 
> --
> M.Ranganathan
> NIST Advanced Networking Technologies Group,
> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
> Tel: 301 975 3664 Fax: 301 590 0932
> 
> Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 16:14:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27081
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 16:14:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B924644337; Wed, 10 Jan 2001 15:15:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id BEA3444336
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 15:14:08 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0ALDi108950;
	Wed, 10 Jan 2001 15:13:44 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: Sean Olson <sean.olson@ericsson.com>
Cc: Billy Biggs <billy@billybiggs.com>, Sip List <sip@lists.bell-labs.com>
Subject: Re: [SIP] REFER progress
Message-ID: <20010110151338.A3402@fdd.com>
References: <20010110130054.B12449@csclub.uwaterloo.ca> <3A5CC4D8.9050504@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A5CC4D8.9050504@ericsson.com>; from sean.olson@ericsson.com on Wed, Jan 10, 2001 at 02:23:52PM -0600
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 15:13:38 -0600

On Wed, Jan 10, 2001 at 02:23:52PM -0600, Sean Olson wrote:
> Allow me to clarify a few things :)
> 
> Billy Biggs wrote:
> 
> >   Maybe I can better explain the issue:
> > 
> >   Say we use REFER to negotiate transfer, and the transfer fails.  Rick
> > wants the REFER receiver to send a re-INVITE back to the REFER sender to
> > re-negotiate the session, not a NOTIFY.  Reasons:
> 
> I never, ever, intended the NOTIFY to be used to re-negotiate
> the session. Session negotiation is what INVITE does.
> NOTIFY was meant as an indication which a service could use
> to determine the success or failure of the REFER. That is all.
> Re-negotiation of the session would happen subsequently or
> perhaps independently of the NOTIFY.
> 
> > 
> >   1. The code on the INVITE receiver can be reused.  The REFER sender
> >      sends a 180 Ringing until the user answers the line.  The INVITE
> >      sending phone correctly plays local ringback.
> 
>        I can't imagine what you are trying to do here.
>        Why does the REFER sender have to worry about ringing
>        at the transferee? Why isn't this left to a "180 Ringing"
>        or otherwise that is received from the transfer target?
>        It seems like you are looking for device control here and
>        I don't think SIP is good at that.
> 
> > 
> >   2. How does the NOTIFY sender know to play local ringing?  Send a 180
> >      response to the NOTIFY?  Should we play ringing in the RTP?
> 
>        Why does the NOTIFY sender need to play local ringing?
>        You are just using an existing session to the REFER sender
>        right? i.e. there is no SIP signalling needed here. The
>        NOTIFY is just a nicety.
> 
> > 
> >   3. The INVITE transaction can take a long time.  NOTIFY can't, meaning
> >      we can't send 180s to the NOTIFY otherwise we get the same problem
> >      we had with REFER.
> >
> 
>        Agreed. This is a very poor use of NOTIFY.
> 
> >   As a compromise, I suggested that the NOTIFY and the REFER allow SDP
> > bodies so that at least we could avoid message queues for re-negotiation
> > of the session.  This way, we can at least send the ringing as audio in
> > an RTP session, and negotiate this session without having a message
> > queue (send NOTIFY then send re-INVITE).  To optimize a successful
> > transfer case, I want to allow a BYE to mean that no NOTIFY will be sent
> > (to avoid send NOTIFY then send BYE).
> 
> I think that the problems you are encountering are because
> of the interdependency of the INVITE/REFER. For this
> particular case (blind transfer with "automatic" session
> re-negotiation upon failure), I would recommend the following:
> 
> 1) The transferor sends a REFER without a Refer-Notify:
>     header indicating that the transferor doesn't care to
>     receive a NOTIFY at all. The transferee immediately
>     responds with a 200 OK to the REFER.
> 
> 2) The transferor immediately sends a BYE. At this point
>     the transferor is completely removed from the situation.
> 
> 3) The transferee sends an INVITE to the transfer target.
> 
> 4) The INVITE fails for whatever reason ...
> 
> 5) The transferee sends a new INVITE to the transferor.
>     This is a brand new session.
> 
> 6) Repeat as necessary ...

This is BYE-Also.  Unreliable.  Keeping around
the old call leg until the new one succeeds better
ensures the call wont be dropped, and can be resolved
faster.  Dropping calls is bad.

> 
> With this message sequence the roles of all the actors at each
> point in the call is well defined. No real magic needed. Granted,
> this probably not what you had in mind -- you wanted the transferor
> to remain on "hold" while the REFER was being handled. I don't
> see any great advantage to this.
> 
> However, if you really want this then:
> 
> 1) The transferor sends a REFER without a Refer-Notify:
>     header indicating that the transferor doesn't care to
>     receive a NOTIFY at all. The transferee immediately
>     responds with a 200 OK to the REFER.
> 
> 2) The transferor "switches to a new line". No SIP
>     signalling needed here. You could, optionally, actually
>     place the transferor on hold here if needed.
>     The transferee sends an INVITE to the transfer target
> 
> 3) The INVITE fails for some reason ...
>     (If the INVITE did not fail, then the transferee could
>      simply send a BYE to the transferor)
> 
> 4) The transferee switches back to the original line
>     (No SIP signalling involved). There is no ringing to
>     worry about, etc. This is based on the concept that there
>     is an actual human user at the transferor UA.
> 

Exactly.  Does the REFER recipient send a NOTIFY?

If no, the the transfer failure has to pass through the
human-band.  "Hello" "Hello" "Did you transfer me?" 
"Didn't it work? Let me try again".

If yes, we need to renegotiate the audio at the same time
we need to send a NOTIFY in the same call-leg, same direction.  
Which message goes first?   Either way you have added
another state.

What was that exception you proposed about the NOTIFY and 
INVITE being independent and thus allowing overlaping
transactions?  Do they use the same CSeq?  I don't like
where this is going.  Please stop.

500-port gateways need to budget their media bandwith carefully.  
Don't assume everyone has enough capacity to support additional
streams, or will mix.  Phones also have problems.

Transfer needs to be easy because it needs to be supported,
especially on the gateways.  We have seen many people
have trouble with the most basic features of SIP.  Who
knew that development time would be the most binding
constraint?  

Is anyone ready to interoperate with me?  Preferrably
against something without a hard disk and 19" monitor.

--
Rick


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 17:00:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28520
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 17:00:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D5FDB44337; Wed, 10 Jan 2001 16:01:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 7C81D44336
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 16:00:24 -0500 (EST)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id OAA08375;
	Wed, 10 Jan 2001 14:00:13 -0800 (PST)
Received: from buckthorn-nt.cisco.com (dhcp-128-107-142-87.cisco.com [128.107.142.87])
	by imop.cisco.com (Mirapoint)
	with ESMTP id AAG81909 (AUTH rmahy);
	Wed, 10 Jan 2001 14:00:08 -0800 (PST)
Message-Id: <5.0.0.25.2.20010110135000.01f30600@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
From: Rohan Mahy <rohan@cisco.com>
Cc: "'Rohan Mahy'" <rohan@cisco.com>, sean.olson@ericsson.com,
        taylor@nortelnetworks.com,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>, bbiggs@div8.net,
        venkatesh.venkataramanan@wipro.com, sip@lists.bell-labs.com
In-Reply-To: <B65B4F8437968F488A01A940B21982BF9AB031@DYN-EXCH-001.dynami
 csoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] RE: Directed Invitation to discuss REFER open issues
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 13:58:59 -0800

Hi,

I have a date (Thurs Feb 8th) that will work for: Sean, Tom, myself, 
Henning, Alan Johnston, Robert Sparks, and Rick Dean.   If we got Billy and 
Jonathan by phone or in person that would cover soemthing like 75% of the 
list traffic on this list.

I will move forward with a meeting on this date with the blessing of 
Henning and Brian Rosen.  If folks want to extend this to Fri Feb 9th and 
possibly Sat Feb 10th to cover open issues, I will do so, but I want at 
least half the day Feb 8th to cover REFER.

thanks,
-rohan


At 10:06 PM 1/9/01, Jonathan Rosenberg wrote:
>It is not worth it to have a face to face with such a small number of
>people.
>
>We need to have a broader face to face that covers more than just REFER.
>Rohan - would you take it on as an action item to work with our working
>group chairs to plan this out?
>
>Thanks,
>Jonathan R.
>
>---
>Jonathan D. Rosenberg                       72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
>http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
>http://www.dynamicsoft.com
>
>
> > -----Original Message-----
> > From: Rohan Mahy [mailto:rohan@cisco.com]
> > Sent: Tuesday, January 09, 2001 3:25 PM
> > To: sean.olson@ericsson.com; taylor@nortelnetworks.com;
> > jdrosen@dynamicsoft.com; bbiggs@div8.net;
> > venkatesh.venkataramanan@wipro.com
> > Subject: Directed Invitation to discuss REFER open issues
> >
> >
> > Hello,
> >
> > Each of you has sent at least 3 email messages about open issues which
> > affect the REFER method, but have not responded to my earlier
> > post.  If you
> > are interested in attending a meeting about these issues,
> > please reply with
> > your availability.
> >
> > thanks,
> > -rohan
> >



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 17:28:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00191
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 17:28:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9B23344354; Wed, 10 Jan 2001 16:29:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 49AD444337
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 16:28:38 -0500 (EST)
Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0AMSOK23808;
	Wed, 10 Jan 2001 16:28:24 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f0AMP0q19131;
	Wed, 10 Jan 2001 16:25:00 -0600 (CST)
Received: from ericsson.com (pc050184.exu.ericsson.se [138.85.50.184]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA04760; Wed, 10 Jan 2001 16:28:23 -0600 (CST)
Message-ID: <3A5CE1F8.7010506@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Rick Dean <siplist@fdd.com>
Cc: Billy Biggs <billy@billybiggs.com>, Sip List <sip@lists.bell-labs.com>
Subject: Re: [SIP] REFER progress
References: <20010110130054.B12449@csclub.uwaterloo.ca> <3A5CC4D8.9050504@ericsson.com> <20010110151338.A3402@fdd.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 16:28:08 -0600
Content-Transfer-Encoding: 7bit

Thank you. The pieces all fell together for me, finally :)
Some minor comments below. For what you want, I agree
that the best solution is to send a re-INVITE with a
Refer-Status: header. Will this go in the transfer draft
or is it an extension to that draft?

/sean


> Exactly.  Does the REFER recipient send a NOTIFY?
> 
> If no, the the transfer failure has to pass through the
> human-band.  "Hello" "Hello" "Did you transfer me?" 
> "Didn't it work? Let me try again".

This is indeed very clumsy.

> 
> If yes, we need to renegotiate the audio at the same time
> we need to send a NOTIFY in the same call-leg, same direction.  
> Which message goes first?   Either way you have added
> another state.
 >

> What was that exception you proposed about the NOTIFY and 
> INVITE being independent and thus allowing overlaping
> transactions?  Do they use the same CSeq?  I don't like
> where this is going.  Please stop.

I didn't see the INVITE/REFER sharing the same
Call-ID. This is why I didn't see the problem
you have. This was the independence I was looking
for. I understand your desire to use the same
Call-ID though.

> 
> 500-port gateways need to budget their media bandwith carefully.  
> Don't assume everyone has enough capacity to support additional
> streams, or will mix.  Phones also have problems.
> 

I try to never make those assumptions. Thus the
option to place the transferor on hold (or vice
versa).

> Transfer needs to be easy because it needs to be supported,
> especially on the gateways.  We have seen many people
> have trouble with the most basic features of SIP.  Who
> knew that development time would be the most binding
> constraint?  

I agree with the sentiment. I don't think any
of the possible approaches we have discussed
are that different in terms of complexity. They
do differ in the way the service looks to the
end user.

> --
> Rick


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 18:08:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03282
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 18:08:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AE65C44339; Wed, 10 Jan 2001 17:09:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from usmlns02.jax.ecitele.com (unknown [12.27.128.28])
	by lists.bell-labs.com (Postfix) with ESMTP id 8BFD744336
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 15:59:32 -0500 (EST)
To: sip@lists.bell-labs.com
X-Mailer: Lotus Notes Release 5.0.1a August 17, 1999
Message-ID: <OF1B47089D.F8FA30B2-ON852569D0.0077F577@jax.ecitele.com>
From: Krishna.Sai@jax.ecitele.com
X-Priority: 3 (Normal)
X-MIMETrack: Serialize by Router on USMLNS02/JAX/ECI Telecom(Release 5.0.1a|August 17, 1999) at
 01/10/2001 05:09:51 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Subject: [SIP] SIP & 3GPP
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 17:09:51 -0500

I am trying to find some refernce to material that talks about the use of
SIP in 3GPP. I would appreciate any pointers to this.

Thanks,

-------------------------------------------------------------
Krishna Sai
904-224-5312
sai@jax.ecitele.com


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 18:21:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03923
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 18:21:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5F4AB44356; Wed, 10 Jan 2001 17:22:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id D2E9B44356
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 17:21:17 -0500 (EST)
Received: from SUPERBEE ([63.110.3.128])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id SAA09265;
	Wed, 10 Jan 2001 18:06:39 -0500 (EST)
From: "Ben Campbell" <bcampbell@dynamicsoft.com>
To: "'Alan Johnston'" <alan.johnston@wcom.com>,
        "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: "Sean Olson" <sean.olson@ericsson.com>,
        "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>,
        "Robert Sparks" <rsparks@dynamicsoft.com>,
        "'Tom-PT Taylor'" <taylor@nortelnetworks.com>,
        "'Rohan Mahy'" <rohan@cisco.com>, "sip" <sip@lists.bell-labs.com>
Subject: RE: [SIP] REFER progress
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3B5BF@DYN-TX-EXCH-001.dynamicsoft.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <3A5BD44E.792A720B@wcom.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 17:00:40 -0600
Content-Transfer-Encoding: 7bit

In response to Alan's point about document structure, I am concerned that
the implicit subscription is not supported in the current version of the
SIP-Events draft. I had previously strongly opposed an implicit
subscription, but am ready to yield that argument based on further
discussion. However, if we do go with an implied subscription, I would like
to make sure the supporting language makes it back into SIP-Events (sorry
Adam :-) ).

I want to avoid the situation where NOTIFY is defined in multiple places
with varying semantics.

Ben.

> -----Original Message-----
> From: Alan Johnston [mailto:alan.johnston@wcom.com]
> Sent: Tuesday, January 09, 2001 9:18 PM
> To: Henning G. Schulzrinne
> Cc: Sean Olson; Fairlie-Cuninghame, Robert; 'Robert Sparks'; 'Tom-PT
> Taylor'; 'Rohan Mahy'; sip
> Subject: Re: [SIP] REFER progress
>
>
> I'd be OK with REFER generating an implicit NOTIFY response
> (instead of
> REFERDONE) as long as:
>
> 1. This usage of NOTIFY is defined in a document separate
> from the other
> presence stuff (maybe even part of the REFER document).  Our
> PSTN Gateways
> will never implement full presence, but we will want them to
> support various
> types of call transfers using REFER.  Writing requirements
> for vendors that
> say "implement only this piece of this document" is problematic.
>
> 2. There are separate event for the progress of the REFERed
> Request (18x
> response received) vs. completion of the REFERed Request
> (final response -
> 2xx or failure).  This way, we can implement all the
> different types of call
> transfers in the PSTN, completely blind transfers, transfers where you
> disconnect after the target phone rings, and fully attended
> transfer where
> you only disconnect after a successful completion of the
> transfer.  I'm not
> necessarily in favor of multiple NOTIFY per REFER, just that the REFER
> should be able to specify which call progress or completion event will
> generate the one and only NOTIFY.
>
>
>
> Thanks,
> Alan Johnston
> WorldCom
>
> "Henning G. Schulzrinne" wrote:
>
> > Sean Olson wrote:
> > >
> > > I have a small problem with this logic. What I am
> > > proposing is perfectly inline with SUB/NOT and is
> > > not a radical deviation from it. I argued for implicit
> > > subscriptions in the SUB/NOT draft specifically for
> > > this type of situation. With regards to the complexity
> > > of the solution using NOTIFY, I don't see much difference
> > > between NOTIFY and REFERDONE in this case. Both will
> > > need to indicate a final response code. The NOTIFY
> > > solution happens to use the Event: header. The body
> > > of the NOTIFY may or may not contain SDP. The
> > > receiving client of course is free to ignore it.
> > > I'm not advocating anything like XML be used for this.
> > > The only modification I would make in a future extension
> > > would be the support of multiple NOTIFYs and this is
> > > *very* easily handled by a client that supports a single
> > > NOTIFY. (Provisional responses in the NOTIFY can simply
> > > be ignored)
> > >
> > > I'm not going to argue forever on this, I promise :)
> > > I just would prefer that NOTIFY be used over REFERDONE
> > > barring any more substantial arguments.
> > >
> >
> > There clearly is no deep technical difference between
> >
> > REFERDONE
> >
> > and
> >
> > NOTIFY
> > Event: Refer-Done
> >
> > However, I believe we've tried to make the point in other
> venues that
> > events are a fundamental mechanism that has broad
> applicability. This
> > smells like an event (as in "let me tell you, something
> happened") as
> > opposed to "do something". Thus, I would find it easier to
> explain the
> > overall architecture if we consistently labeled
> (call-related and other)
> > events as NOTIFY rather than inventing a new method name
> for each type
> > of event. By that logic, we should have PRESENT and NOT-PRESENT and
> > VOICEMAIL-ARRIVED and who knows what else. Can be done,
> just seems like
> > it degnerates into an unstructured list of dozens of
> methods rather than
> > some logical hierarchy of "this is an event, with a type label".
> >
> > As has been pointed out in addition, there is no complexity
> benefit to
> > limiting notification just to completion of the referred
> operation. We
> > may want other status updates in the future and I certainly
> don't want
> > to invent a new method for each.
> > --
> > Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 18:40:50 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04761
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 18:40:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B5A6044356; Wed, 10 Jan 2001 17:41:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 753E54433F
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 17:40:15 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA08637;
	Wed, 10 Jan 2001 18:39:56 -0500 (EST)
Message-ID: <3A5CF2CC.CCD61470@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Sean Olson <sean.olson@ericsson.com>
Cc: Billy Biggs <billy@billybiggs.com>, Rick Dean <siplist@fdd.com>,
        Sip List <sip@lists.bell-labs.com>
Subject: Re: [SIP] REFER progress
References: <20010110130054.B12449@csclub.uwaterloo.ca> <3A5CC4D8.9050504@ericsson.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 18:39:56 -0500
Content-Transfer-Encoding: 7bit

Sean Olson wrote:
> 

> 
> With this message sequence the roles of all the actors at each
> point in the call is well defined. No real magic needed. Granted,
> this probably not what you had in mind -- you wanted the transferor
> to remain on "hold" while the REFER was being handled. I don't
> see any great advantage to this.

Generally, I think 'hold' is a poor UI choice for longer-duration
interruptions.  It means that a long-forgotten call can suddenly come
back with a mysterious voice starting to talk.  Just because PBX do it
that way doesn't mean that we should. I would find it very peculiar to
suddenly have the person that I thought I handed off to somebody else
talk to me after a minute or two.  (Also, note that the In-Reply-To
header can provide hints that this is "return engagement" has a
relationship with an older call. The UI is then free to do something
special if desired.)


> 
> However, if you really want this then:
> 
> 1) The transferor sends a REFER without a Refer-Notify:
>     header indicating that the transferor doesn't care to
>     receive a NOTIFY at all. The transferee immediately
>     responds with a 200 OK to the REFER.
> 
> 2) The transferor "switches to a new line". No SIP
>     signalling needed here. You could, optionally, actually
>     place the transferor on hold here if needed.
>     The transferee sends an INVITE to the transfer target
> 
> 3) The INVITE fails for some reason ...
>     (If the INVITE did not fail, then the transferee could
>      simply send a BYE to the transferor)
> 
> 4) The transferee switches back to the original line
>     (No SIP signalling involved). There is no ringing to
>     worry about, etc. This is based on the concept that there
>     is an actual human user at the transferor UA.
> 
> This seems a little too obvious. I must be missing a fundamental
> requirement/feature of the service you are trying to build.

This is basically attended transfer, right?

Given the ease with which multiple "lines" can be implemented in SIP
phones, the traditional distinction between attended and unattended
transfer may not matter that much. 



-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 18:53:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04874
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 18:53:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E0D7144338; Wed, 10 Jan 2001 17:54:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cybertron.div8.net (HSE-Kitchener-ppp195174.sympatico.ca [64.229.15.253])
	by lists.bell-labs.com (Postfix) with ESMTP id 440CE44337
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 17:53:34 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m14GV3q-003ErKC@cybertron.div8.net> (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Wed, 10 Jan 2001 18:53:46 -0500 (EST) 
From: Billy Biggs <billy@billybiggs.com>
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: Sean Olson <sean.olson@ericsson.com>, Rick Dean <siplist@fdd.com>,
        Sip List <sip@lists.bell-labs.com>
Subject: Re: [SIP] REFER progress
Message-ID: <20010110185346.A981@div8.net>
References: <20010110130054.B12449@csclub.uwaterloo.ca> <3A5CC4D8.9050504@ericsson.com> <3A5CF2CC.CCD61470@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A5CF2CC.CCD61470@cs.columbia.edu>; from hgs@cs.columbia.edu on Wed, Jan 10, 2001 at 06:39:56PM -0500
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 18:53:46 -0500

Henning G. Schulzrinne (hgs@cs.columbia.edu):

> Generally, I think 'hold' is a poor UI choice for longer-duration
> interruptions.

  The line would likely "disappear" from the UI or be hidden or
something.  The re-INVITE after failure would then cause the phone to
ring as if it was an incoming call.

> (Also, note that the In-Reply-To header can provide hints that this is
> "return engagement" has a relationship with an older call. The UI is
> then free to do something special if desired.)

  We want to use the existing session, re-INVITE rather than a new
INVITE, in order to avoid forking and make recovery reliable.

> > However, if you really want this then:
> > 
> > 1) The transferor sends a REFER without a Refer-Notify: [...]
> > 2) The transferor "switches to a new line". [...]
> > 3) The INVITE fails for some reason ... [...]
> > 4) The transferee switches back to the original line [...]
> > 
> > This seems a little too obvious. I must be missing a fundamental
> > requirement/feature of the service you are trying to build.
> 
> This is basically attended transfer, right?

  No.   Attended transfer is when a bridge excuses itself from a 3-way
call, connecting the two endpoints it was conversing with directly.

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 19:34:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06273
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 19:34:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2953844337; Wed, 10 Jan 2001 18:35:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 6470A44336
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 18:34:14 -0500 (EST)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id QAA06466;
	Wed, 10 Jan 2001 16:34:04 -0800 (PST)
Received: from buckthorn-nt.cisco.com (dhcp-128-107-142-87.cisco.com [128.107.142.87])
	by imop.cisco.com (Mirapoint)
	with ESMTP id AAG84058 (AUTH rmahy);
	Wed, 10 Jan 2001 16:34:00 -0800 (PST)
Message-Id: <5.0.0.25.2.20010110155640.01f689d0@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
To: Billy Biggs <billy@billybiggs.com>
From: Rohan Mahy <rohan@cisco.com>
Subject: Re: [SIP] REFER progress
Cc: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
        Sean Olson <sean.olson@ericsson.com>, Rick Dean <siplist@fdd.com>,
        Sip List <sip@lists.bell-labs.com>
In-Reply-To: <20010110185346.A981@div8.net>
References: <3A5CF2CC.CCD61470@cs.columbia.edu>
 <20010110130054.B12449@csclub.uwaterloo.ca>
 <3A5CC4D8.9050504@ericsson.com>
 <3A5CF2CC.CCD61470@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 16:32:59 -0800

Hi,

We need to go back to the requirements.  Callback on transfer failure is a 
nice feature, but you and Rick seem to be assuming that this feature is 
common enough to merit special optimizations.  I'm not convinced.  Maybe we 
will decide the proposed optimization (Event header in any method) is 
useful and simple or benign enough to make it a standard, but let everyone 
see the complete picture before we decide.

thanks,
-rohan




At 03:53 PM 1/10/01, Billy Biggs wrote:
>Henning G. Schulzrinne (hgs@cs.columbia.edu):
>
> > Generally, I think 'hold' is a poor UI choice for longer-duration
> > interruptions.
>
>   The line would likely "disappear" from the UI or be hidden or
>something.  The re-INVITE after failure would then cause the phone to
>ring as if it was an incoming call.
>
> > (Also, note that the In-Reply-To header can provide hints that this is
> > "return engagement" has a relationship with an older call. The UI is
> > then free to do something special if desired.)
>
>   We want to use the existing session, re-INVITE rather than a new
>INVITE, in order to avoid forking and make recovery reliable.
>
> > > However, if you really want this then:
> > >
> > > 1) The transferor sends a REFER without a Refer-Notify: [...]
> > > 2) The transferor "switches to a new line". [...]
> > > 3) The INVITE fails for some reason ... [...]
> > > 4) The transferee switches back to the original line [...]
> > >
> > > This seems a little too obvious. I must be missing a fundamental
> > > requirement/feature of the service you are trying to build.
> >
> > This is basically attended transfer, right?
>
>   No.   Attended transfer is when a bridge excuses itself from a 3-way
>call, connecting the two endpoints it was conversing with directly.
>
>--
>Billy Biggs                     bbiggs@dumbterm.net
>http://www.billybiggs.com/      wbiggs@uwaterloo.ca
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 19:53:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07827
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 19:53:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3014844361; Wed, 10 Jan 2001 18:54:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 9E77944336
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 18:53:41 -0500 (EST)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id RAA12355; Wed, 10 Jan 2001 17:51:13 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id RAA08249; Wed, 10 Jan 2001 17:51:10 -0700 (MST)]
Received: from arc.corp.mot.com (ltd.arc.corp.mot.com [217.1.10.133])
	by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id f0B0lOS06765;
	Thu, 11 Jan 2001 11:47:24 +1100 (EST)
Message-ID: <3A5D0192.7DBADC61@arc.corp.mot.com>
From: Jack Yu <jyu@arc.corp.mot.com>
Organization: Motorola Australian Research Centre
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en,zh,zh-CN,zh-TW
MIME-Version: 1.0
To: Krishna.Sai@jax.ecitele.com
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SIP & 3GPP
References: <OF1B47089D.F8FA30B2-ON852569D0.0077F577@jax.ecitele.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 11:42:59 +1100
Content-Transfer-Encoding: 8bit

The exact signalling and call control protocols are defined in 3GPP
Technical Specification 3G TS 24.228: “Signalling flows for the IP
multimedia call control based on SIP and SDP” and 3GPP Technical
Specification 3G TS 24.229: “IP Multimedia Call Control Protocol based
on SIP and SDP”.

Regards,
Jack

Krishna.Sai@jax.ecitele.com wrote:

> I am trying to find some refernce to material that talks about the use of
> SIP in 3GPP. I would appreciate any pointers to this.
>
> Thanks,
>
> -------------------------------------------------------------
> Krishna Sai
> 904-224-5312
> sai@jax.ecitele.com
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

--
Zhenghua (Jack) Yu, Ph.D.
Motorola Australian Research Centre



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Wed Jan 10 20:32:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08475
	for <sip-archive@odin.ietf.org>; Wed, 10 Jan 2001 20:32:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1BC0D44337; Wed, 10 Jan 2001 19:33:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from aphrodite.systems.cfer.com (voyantteer-u5.voyanttech.com [63.89.131.5])
	by lists.bell-labs.com (Postfix) with ESMTP id 8EE8144336
	for <sip@lists.bell-labs.com>; Wed, 10 Jan 2001 19:32:03 -0500 (EST)
Received: from voyanttech.com ([192.168.55.13])
	by aphrodite.systems.cfer.com (8.8.8+Sun/8.8.8) with ESMTP id SAA27692;
	Wed, 10 Jan 2001 18:31:38 -0700 (MST)
Message-ID: <3A5D2005.C6F9A166@voyanttech.com>
From: Doug Harbert <dough@voyanttech.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
Cc: sip@lists.bell-labs.com, Keith Robinson <Keith.Robinson@marconi.com>
Subject: Re: [SIP] Overlap Sending
References: <802569D0.003887E7.00@marconicomms.com> <3A5C4C18.39554C0C@lmf.ericsson.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 19:52:53 -0700
Content-Transfer-Encoding: 7bit

Christer:

Christer Holmberg wrote:

> Hi,
>
> >If we say that the 484 clears down the call attempt and therefore associated
> >state in the preceding SIP nodes then I have no problem with generating a new initial INVITE with a new
> >TO header; this seems consistent with the RFC. Note that the paragraph in section 4.2.1 starting
> >"A UAS acting as a gateway.." implies that the UAS that generated the 484 does not kill associated state with
> >this call attempt.
> >
> >So, the problem I have with using the same Call-Id though  is
> >that it is unclear from the RFC what a UAS will make of the received request.
>
> One idea would be to write that an UAS that sends a 484 response and
> KNOWS it may receive a new INVITE with more digits (a gateway, for
> example) MUST accept the same Call-ID (the To header is different,
> though).
>

    What if the caller cannot supply any more digits? When will the UAS be able to discard the saved call state?

>
> >Referring to section 11.5 we get to case 3, where a request has been received with a Call-Id that matches
> >a current; however case 3 only explains the meaning of the request if the To and From fields match
> >stored values at this point, - "the request is a new transaction for an existing leg", it does not explain >what it means if either the From or To fields are differ.
>
> My understanding that when we have sent the 484 we don't have an
> existing leg anymore. The UAS does have an ongoing transaction, waiting
> for the ACK, but since we will send a new To header in the next INVITE
> we will not mess with that transaction even if the Call-ID is the same.
>
> >Is it an update to either field ?
>
> I think that since multiple headers are used to define a call-leg, we
> have a different call-leg as soon as one of them change, even if the
> other headers (including the Call-ID) remains the same.
>
> >Is it a request for a new leg ? Is it erroneous. I have raised this
> >as a seperate question on the list as it is probably a more general problem.
> >
> >I think it is therefore safest for the 484 to kill that call attempt and
> >associated state completely, including within the terminating UAS that generated it. INVITES carrying the >subsequent digits (plus original digits) in the TO field will  then be treated as brand new call attempts with >no ambiguity.
> >
> >I am not advocating that this is the best solution, just the safest without
> >significant change to the RFC.
>
> I agree. It is the safest, but not the fastest, since the gateway will
> delete any possible information it could have used for the subsequent
> INVITE.

    I think that assuming the 484 clears down the call attempt is the best solution. The transaction is complete when the UAS receives the ACK to this final response. The UAC that knows how to gather additional digits knows that the
call hasn't actually failed and can then issue a new INVITE with the additional digits. A UAC that doesn't know how to gather additional digits assumes that the call has failed. This is not much different from behavior on receiving 401
response. The UAC gathers more information (username and password) and issues a new INVITE to complete the call.

Doug Harbert

>
>
> >As I said previously, I believe a better solution would be to able to send
> >re-INVITES after an infomational response, but before the final ACK. Of course, this would mean the TO field >has to remain consistent for all these re-INVITES so could not be used to carry the subsequent digits.........
>
> I agree. In that case I guess we would need a separate header, or a new
> To header parameter, to transport the subsequent digits.
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
> >Advive on this matter from the SIP authors would be gratefully appreciated.
>
> > Regards,
> >
> > K. Robinson.
> >
> > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 09/01/2001 10:50:06
> >
> >
> >
> >
> >
> >
> >
> >  To:      sip@lists.bell-labs.com
> >
> >  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
> >           <stlevy@cisco.com>
> >
> >
> >
> >  Subject: Re: [SIP] Overlap Sending
> >
> >
> > Hi,
> >
> > >I take your point about requiring a proxy to route 6543231@sipgw.com the same
> > >way as 65432@sipgw.com but I believe this to be entirely within the routing
> > data
> > >set up by the administration. Allowing clients to choose there own path through
> > the
> > >network to get to their desired destination using various digit sequences seems
> > like the
> > >classic way of exposing networks to fraudulent use (billing avoidance,
> > bypassing security,
> > >etc). However, I think this is a seperate issue.
> >
> > Well, it's related :)
> >
> > >I am still concerned about the Route header overwriting the R-URI and therefore
> > >destroying the subsequent digits when subsequent messages are routed using the
> > Route header mechanism. I
> > >am not sure that putting the subsequent digits in the TO header helps because I
> > believe the TO
> > >URL is supposed to be invariant during the lifetime of the call leg.
> >
> > Well, this depends a little on how you define a call leg, I guess...
> > Since you got a 4xx response to your first INVITE, you didn't manage to
> > set up a call leg, so then you try to set up a "new" call leg - with a
> > new R-URI and To header...
> >
> > INVITE 123@sipgw.com
> > To: 123@sipgw.com
> >
> > <---- 484 -----
> >
> > INVITE 123456@sipgw.com
> > To: 123456@sipgw.com
> >
> > >Modifying the TO URL after the initial INVITE I think will cause problems for
> > proxies  that are using the TO >URL to match subsequent requests to call legs in
> > progress.
> >
> > Since the proxy sent back 484, I wouldn't consider the call leg to be in
> > progress anymore (after the proxy receive the ACK, that is).
> >
> > And, the proxy will probably have to do the routing based on the To
> > header, since the R-URI will probably (unless we use an outbound proxy)
> > be the address of the proxy itself, so if the To header isn't changed
> > the proxy will try to route 123@sipgw.com every time, even if more
> > digits have provided by the client. And, if the proxy is supposed to
> > "combine" the Current-Dial-String header value with the To header, to be
> > able to route, I think that the client could put the new value in the To
> > header from the beginning. Because, if the proxy doesn't support the
> > Current-Dial-String it wouldn't be able to do anything, since both the
> > R-URI and To header could be the same in the subsequent INVITEs. If you
> > have a updated To header, and the proxy doesn't support the digitmap, it
> > would at least be able to route the new To header - even if the message
> > may take a "wrong" route.
> >
> > >Without introducing a new header to carry the digit string, then I think the
> > >only other way to make overlap sending work is for the 484 to clear down the
> > call leg as other 4XX
> > >responses do and subsequent INVITES with the original digits + additional
> > digits to be a new INVITE (with a
> > >new Call-Id).
> >
> > I agree, but I don't think it requires a new Call-Id. Then we could
> > still define a digitmap header to make sure  (if it is supported by the
> > proxy) that the proxy will always route the message correctly, no matter
> > how many INVITEs you need to provide all digits.
> >
> > >The initial INVITE will not be routed using Route headers, so the digit string
> > in the R-URI will
> > >not be lost.
> >
> > Proxies may change the R-URI...
> >
> > >There still could be a problem if the client has built a Route header (learnt
> > out-of-band) and puts
> > >this in the initial INVITE; the same problem may occur.
> >
> > This will not be a problem if all servers in the path support the
> > digitmap... :)
> >
> > >Without clarification of this matter in the bis draft then I don't think
> > overlap
> > >sending is going to be interoperable.
> >
> > I agree.
> >
> > Personally I think (no, this is NOT a proposal to re-write SIP :) the
> > best way would be to have some kind of "multi-message" setup, and that
> > would also solve a number of other issues (i.e. ISUP transparency).
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> > Keith Robinson wrote:
> > >
> > > Let's consider the following point:
> > >
> > > "I don't know. I haven't seen a proxy that would route depending on the
> > > user, but it COULD happend. Let's assume , for example, that you do a
> > > SRV DNS lookup, and get a list of servers. Then you MAY choose a
> > > different server, for load balance purpose e.g., depending on the user
> > > name. Just an example..."
> > >
> > > One way of ensuring that subsequent requests always traverse a given SIP
> > > node is for that node to Record-Route or supply a Contact ; it is likely that
> > > proxies and
> > > UAS at PSTN interworking points will require to stay in the signalling path
> > > during
> > > call setup so will do so.  Now, suppose one such node receives an initial
> > INVITE
> > > with
> > > a R-URI of sip:654@sipgw.com and creates a Contact header thus:
> > >
> > > Contact: sip:654@sipgw.com;maddr=sipgw.com
> > >
> > > This is then returned in the 484 response so that the sending UA may build a
> > > Route header from it. Here is my first concern; will the sending UA treat the
> > > subsequent INVITE as a subsequent INVITE or as a new INVITE on a new
> > > Call-Id ? I ask because the 484 response is non-200 final response which
> > > implies that that call attempt has failed; obviously in this case it hasn't
> > > failed
> > > (not yet, anyway) its just been partially set up.  Does this lead to special
> > > case handling
> > > for a particular 4XX response ? In fact, the 484 is almost like an
> > informational
> > > response.
> > > Would it be better to send an informational response (say 183) and the spec
> > > updated to
> > > allow subsequent INVITEs to be sent before the final ACK (a point raised by J.
> > > Rosenberg
> > > earlier on the list, but in a different context - to convey updated SDP
> > > information).
> > >
> > > Assuming the above is resolved one way or another, then a SIP node preceding
> > > sipgw.com is going to receive a subsequent INVITE for this call (containing
> > > additional
> > > digits 321)  that will look something like:
> > >
> > > INVITE sip:321@preceding.sipgw.com
> > > Route: sip:654@sipgw.com;maddr=sipgw.com
> > >
> > > As a Route header is present, this will be used to route the INVITE so
> > > therefore sipgw.com will receive an INVITE with the following Request
> > > Line:
> > >
> > > INVITE sip:654@sipgw.com;maddr=sipgw.com
> > >
> > > And here is a more worrying problem, the subsequent digits have been lost.
> > > The situation would be no better if the subsequent INVITE contained original
> > > digits
> > > plus subsequent digits; they would still be lost.
> > >
> > > The problem stems from the fact that the R-URI is supposed to be invariant at
> > > each
> > > node during the lifetime of the call leg, yet to do overlap sending it is
> > being
> > > used to
> > > convey new information so therefore does not remain invariant and other parts
> > of
> > > the
> > > protocol which assume it is invariant e.g., routing using the Route header
> > > break.
> > >
> > > Using a TEL URL does not help either; the digits would still be lost after the
> > > popping of
> > > the Route entry into the R-URI.
> > >
> > > It would be easier to implement overlap sending if a seperate header could be
> > > used to
> > > convey the dialled digits, so an original INVITE may look something like:
> > >
> > > INVITE sip:digitdecode@sipgw.com
> > > Current-Dial-String: 01623
> > >
> > > The subsequent INVITES would then look something like:
> > >
> > > INVITE sip:digitdecode@sipgw.com;maddr=sipgw.com
> > > Current-Dial-String: 01623654398
> > >
> > > This ties in with your point of implementing a digit map header.
> > >
> > > Regards,
> > >
> > > K. Robinson.
> > >
> > > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 13:40:47
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  To:      sip@lists.bell-labs.com
> > >
> > >  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
> > >           <stlevy@cisco.com>
> > >
> > >
> > >
> > >  Subject: Re: [SIP] Overlap Sending
> > >
> > >
> > > Hi,
> > >
> > > >If a proxy, not serving uas.com, receives an INVITE with a R-URI of
> > 4@uas.com,
> > > >why would it route it differently (Route headers not withstanding) from an
> > > INVITE
> > > >with a R-URI of 441@uas.com ?
> > >
> > > I don't know. I haven't seen a proxy that would route depending on the
> > > user, but it COULD happend. Let's assume , for example, that you do a
> > > SRV DNS lookup, and get a list of servers. Then you MAY choose a
> > > different server, for load balance purpose e.g., depending on the user
> > > name. Just an example...
> > >
> > > And, what happen if you use a TEL-URL, where you have to route depending
> > > on the user name (=telephone number). I guess using a ENUM DNS lookup
> > > COULD route it to the same host, but then I guess you would have to
> > > configure your DNS to for all the possible combinations (4.e164.arpa,
> > > 44.e164.arpa and 441.e164.arpa)...
> > >
> > > >Surely, if the proxy does not serve the domain identified in the R-URI it
> > > cannot
> > > >make any routing decisions based on the user part of the R-URI.
> > > >If, on the other hand, the proxy does serve uas.com, then it will be involved
> > > in
> > > >routing the call using the dialled digit string and I would expect it to know
> > > such things as minimum digits to
> > > >translation and perhaps even maximum number of digits to follow. Also,
> > because
> > > the proxy is doing digit based
> > > >routing it must be subject to the requirements of overlap sending so I would
> > > expect it to be stateful, at >least until call setup is complete, in which
> > case
> > > remembering previous call information would be reasonable. >In fact, such a
> > > proxy appears much like the interworking UAs I referred to previously and to
> > > which my question >applies.
> > >
> > > That was my point - that you also have to have support for this in your
> > > proxies, and not only in your client.
> > >
> > > I think the issue is that there are lots of what-ifs involved in this,
> > > and it should be specified how the specific cases are handled -
> > > especially by proxies and redirect servers.
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > > > Regards,
> > > >
> > > > K. Robinson
> > > >
> > > > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > Keith Robinson wrote:
> > > >
> > > > If a proxy, not serving uas.com, receives an INVITE with a R-URI of
> > 4@uas.com,
> > > > why
> > > > would it route it differently (Route headers not withstanding) from an
> > INVITE
> > > > with a R-URI of 441@uas.com ?
> > > > Surely, if the proxy does not serve the domain identified in the R-URI it
> > > cannot
> > > > make any
> > > > routing decisions based on the user part of the R-URI.
> > > >
> > > > If, on the other hand, the proxy does serve uas.com, then it will be
> > involved
> > > in
> > > > routing the call using the dialled
> > > > digit string and I would expect it to know such things as minimum digits to
> > > > translation and perhaps even
> > > > maximum number of digits to follow. Also, because the proxy is doing digit
> > > based
> > > > routing it must be subject to the
> > > > requirements of overlap sending so I would expect it to be stateful, at
> > least
> > > > until call setup is complete, in which
> > > > case remembering previous call information would be reasonable. In fact,
> > such
> > > a
> > > > proxy appears much like the
> > > > interworking UAs I referred to previously and to which my question applies.
> > > >
> > > > Regards,
> > > >
> > > > K. Robinson
> > > >
> > > > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >  To:      sip@lists.bell-labs.com
> > > >
> > > >  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
> > > >           <stlevy@cisco.com>
> > > >
> > > >
> > > >
> > > >  Subject: Re: [SIP] Overlap Sending
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I think sending re-INVITES containing only subsequent digits will create
> > > > some problems. It's not enough that the UAS remembers the previous
> > > > INVITEs for the specific Call-ID, you may also have intermediate
> > > > redirect- and/or proxy servers that make their redirect/forwarding
> > > > decissions based on the destination number, and then they would also
> > > > have to remember the previous INVITEs, and they would possible also have
> > > > to be able to know if, and in some cases, how many digits will follow
> > > > (e.g. 4@uas.com may be routed to a complete destination than
> > > > 441@uas.com, etc.) Maybe we should implement some kind of digit-map
> > > > header, or something... :)
> > > >
> > > > Regards,
> > > >
> > > > Christer Holmberg
> > > > Ericsson Finland
> > > >
> > > > Keith Robinson wrote:
> > > > >
> > > > > Yes, this is the type of case I have in mind. The question I have is what
> > > are
> > > > > the subsequent INVITES; are they
> > > > >
> > > > > a) New INVITES, on a new Call-Id containing the original digits (from
> > > original
> > > > > INVITE) + subsequent digits ?
> > > > >
> > > > > or
> > > > >
> > > > > b) re-INVITES containing only subsequent digits ?
> > > > >
> > > > > or
> > > > >
> > > > > c) re-INVITES containing original digits + subsequent digits ?
> > > > >
> > > > > The sending UAs I referred to in my previous note are those that sit in
> > > > PSTN/SIP
> > > > > gateways,
> > > > > not necessarily an originating UA sitting on someones desktop.
> > > > >
> > > > > So, the question applies as much to these interworking UAs for
> > constructing
> > > > > the subsequent INVITEs as well as to receiving UAs for interpreting them.
> > > > >
> > > > > Regards,
> > > > >
> > > > > K. Robinson.
> > > > >
> > > > > Steve Levy <stlevy@cisco.com> on 05/01/2001 22:32:00
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >  To:      Keith Robinson/MAIN/MC1@MCMAIN,
> > > > >           sip@lists.bell-labs.com
> > > > >
> > > > >  cc:
> > > > >
> > > > >
> > > > >
> > > > >  Subject: Re: [SIP] Overlap Sending
> > > > >
> > > > >
> > > > > Hi Keith,
> > > > >
> > > > > I was wondering if in considering overlap sending issues and SIP if you
> > were
> > > > > considering the case of overlap sending across multiple networks with
> > > variable
> > > > > length digits.
> > > > >
> > > > > In this case, in order to avoid post dial delay, the digits need to be
> > > passed
> > > > > through the networks to the final destiantion network prior to end of dial
> > > > > (since the destination network is the only network that knows how many
> > > digits
> > > > > are required). So in effect there may be additional digits sent after an
> > > > INVITE
> > > > > has been received and sent downstream to the callee.
> > > > >
> > > > > Thanks,
> > > > > Steve
> > > > >
> > > > > At 03:50 PM 1/5/01 +0000, Keith Robinson wrote:
> > > > > >
> > > > > >
> > > > > >I have the following query regarding overlap sending as defined in
> > > > > >rfc2543bis-02:
> > > > > >
> > > > > >Section 4.2.1 states the following:
> > > > > >
> > > > > >"...the UAS compares the Request-URI with Request-URI of the previous
> > > INVITE
> > > > > >request
> > > > > >for the same Call-Id. If the Request-URI  contains additional digits in
> > the
> > > > > >'user' part, the UAS
> > > > > >treats the INVITE as adding additional digits to the original dialed
> > > string."
> > > > > >
> > > > > >This appears to imply that the subsequent INVITE contains the original
> > > > dialled
> > > > > >string plus the
> > > > > >additional digits; if this is the case, then there is no need for the UAS
> > > to
> > > > > >remember the
> > > > > >previous string, and therefore no need to keep any state regarding the
> > > > previous
> > > > > >attempt.
> > > > > >The subsequent INVITE can really be a new INVITE., i.e. a new Call-Id.
> > > > > >
> > > > > >If, on the other hand, the sending UA only sends additional digits, then
> > > the
> > > > > >original digits
> > > > > >will have to be remembered by the UAS, and the INVITE matched up with
> > this
> > > > > >state
> > > > > >so
> > > > > >this INVITE must be on the same Call-Id.
> > > > > >
> > > > > >This latter case is similar to the way existing telephony protocols
> > > transmit
> > > > > >addtional digits
> > > > > >when doing overlap sending.
> > > > > >
> > > > > >So, upon receiving a response of 484 Address Incomplete, does the sending
> > > UA
> > > > > >send
> > > > > >original digits plus aditional digits on a new Call-Id or additional
> > digits
> > > > > >only
> > > > > >on the same
> > > > > >Call-Id with an incremented Cseq.
> > > > > >
> > > > > >Regards,
> > > > > >
> > > > > >K. Robinson.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >_______________________________________________
> > > > > >SIP mailing list
> > > > > >SIP@lists.bell-labs.com
> > > > > >http://lists.bell-labs.com/mailman/listinfo/sip
> > > > >
> > > > > _______________________________________________
> > > > > SIP mailing list
> > > > > SIP@lists.bell-labs.com
> > > > > http://lists.bell-labs.com/mailman/listinfo/sip
> > > > >
> > > > > _______________________________________________
> > > > > SIP mailing list
> > > > > SIP@lists.bell-labs.com
> > > > > http://lists.bell-labs.com/mailman/listinfo/sip


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 02:18:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27122
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 02:18:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1FC8744337; Thu, 11 Jan 2001 01:19:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web9808.mail.yahoo.com (web9808.mail.yahoo.com [216.136.129.34])
	by lists.bell-labs.com (Postfix) with SMTP id A8F9A44336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 01:18:49 -0500 (EST)
Message-ID: <20010111071837.74620.qmail@web9808.mail.yahoo.com>
Received: from [203.197.174.36] by web9808.mail.yahoo.com; Wed, 10 Jan 2001 23:18:37 PST
From: laks hmi <lakshmiam@yahoo.com>
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] SIP-URL
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 23:18:37 -0800 (PST)

Hi All,

In rfc, they have told to exclude the delimiters used
for Request-URI inside . But in the authorize and
authenticate headers, SIP-URL is coming in cotes, but
cotes and space can also come in the
telphone-subscirber. 

pl clarify this.

lakshmi



__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 02:21:01 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27149
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 02:21:01 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4E17B44345; Thu, 11 Jan 2001 01:19:11 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web9801.mail.yahoo.com (web9801.mail.yahoo.com [216.136.129.211])
	by lists.bell-labs.com (Postfix) with SMTP id 586CA44336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 01:18:57 -0500 (EST)
Message-ID: <20010111071845.89637.qmail@web9801.mail.yahoo.com>
Received: from [203.197.174.36] by web9801.mail.yahoo.com; Wed, 10 Jan 2001 23:18:45 PST
From: laks hmi <lakshmiam@yahoo.com>
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] SIP-URL
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 10 Jan 2001 23:18:45 -0800 (PST)

Hi All,

In rfc, they have told to exclude the delimiters used
for Request-URI inside . But in the authorize and
authenticate headers, SIP-URL is coming in cotes, but
cotes and space can also come in the
telphone-subscirber. 

pl clarify this.

lakshmi



__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 04:09:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27846
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 04:09:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A31A444337; Thu, 11 Jan 2001 03:10:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id B1E5A44336
	for <SIP@lists.bell-labs.com>; Thu, 11 Jan 2001 03:09:17 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 11 Jan 2001 09:09:06 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id JAA19753; Thu, 11 Jan 2001 09:07:50 GMT
From: "Jo Hornsby" <jhornsby@ubiquity.net>
To: "Bertil Engelholm" <Bertil.Engelholm@uab.ericsson.se>
Cc: <SIP@lists.bell-labs.com>
Subject: RE: [SIP] CANCEL problem ??
Message-ID: <000201c07bad$f9465a70$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <3A5B1851.C9CB30F7@uab.ericsson.se>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 09:07:50 -0000
Content-Transfer-Encoding: 7bit

Bertil Engelholm wrote:
>
> Jo Hornsby wrote:
> > 
> > Almost.  The proxy should do as you say; however, it should
> > not send the 487; rather, it should wait for responses on
> > all branches as it normally would do.
> > 
> > There is an issue here, however, if a proxy happens to have
> > an "older" (i.e., non-487 aware) server at the end of one of
> > its branches.  In this case, it will probably not get a final
> > response to the INVITE (or whatever).  A solution to this is
> > to start a timer when a CANCEL has been issued, and if this
> > timer expires, then "imagine" that you got a 487 along that
> > branch.
> > 
> > The difficulty is what value to use for the timer.  There
> > was some discussion about this a while back. Have a look at
> > the thread entitled:
> > "CANCEL - response sequence issue (again)"
> > (it was mid-late October).
> > 
> 
> OK, I have read the thread and I think I understand better know.
> I thought that the 200 response to CANCEL meant that the CANCEL
> was executed OK. From what you are saying and the above thread
> I get the impression that the 200 OK to CANCEL is just a 
> confirmation that you have received the CANCEL request. It's 
> the final response to the original request that tells you if 
> the cancelling actually was done or not. 
> Is this correct understood ?

Sounds about right to me.  The thing is with CANCEL it doesn't
really matter what the response code is -- once it has been
acknowledged, what else can you realistically do?  (If you get
a non-200 -- say a 481 -- it means that either you messed up the
CANCEL request, or the responding server is a bit dull; in any
case, it's not realistically a recoverable situation.)  As far
as I'm concerned, a (final) response to a CANCEL only serves to
stop message retransmission.

Cheers,


 - Jo.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 04:15:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27872
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 04:15:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AD92A4434A; Thu, 11 Jan 2001 03:16:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id E242B44336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 03:15:42 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f0B9Ebd04777;
	Thu, 11 Jan 2001 10:14:39 +0100 (MET)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.64])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA25229;
	Thu, 11 Jan 2001 11:14:21 +0200 (EET)
Message-ID: <3A5D795B.1F04D4FB@lmf.ericsson.se>
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Cc: Doug Harbert <dough@voyanttech.com>,
        Keith Robinson <Keith.Robinson@marconi.com>
Subject: Re: [SIP] Overlap Sending
References: <802569D0.003887E7.00@marconicomms.com> <3A5C4C18.39554C0C@lmf.ericsson.se> <3A5D2005.C6F9A166@voyanttech.com>
Content-Type: multipart/mixed;
 boundary="------------95D56C423D7C2FC0AA914F17"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 11:14:03 +0200

This is a multi-part message in MIME format.
--------------95D56C423D7C2FC0AA914F17
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

>>>If we say that the 484 clears down the call attempt and therefore associated
>>>state in the preceding SIP nodes then I have no problem with generating a new initial INVITE with a new
>>>TO header; this seems consistent with the RFC. Note that the paragraph in section 4.2.1 starting
>>>"A UAS acting as a gateway.." implies that the UAS that generated the 484 does not kill associated state >>>with this call attempt.
>>>
>>>So, the problem I have with using the same Call-Id though  is
>>>that it is unclear from the RFC what a UAS will make of the received request.
>>
>>One idea would be to write that an UAS that sends a 484 response and
>>KNOWS it may receive a new INVITE with more digits (a gateway, for
>>example) MUST accept the same Call-ID (the To header is different,
>>though).
>>
>What if the caller cannot supply any more digits? When will the UAS be able to discard the saved call state?

I guess one easy way would be to use a timer (we do that in the PSTN
network too, so...).

>>>Referring to section 11.5 we get to case 3, where a request has been received with a Call-Id that matches
>>>a current; however case 3 only explains the meaning of the request if the To and From fields match
>>>stored values at this point, - "the request is a new transaction for an existing leg", it does not explain >>>what it means if either the From or To fields are differ.
>>
>>My understanding that when we have sent the 484 we don't have an
>>existing leg anymore. The UAS does have an ongoing transaction, waiting
>>for the ACK, but since we will send a new To header in the next INVITE
>>we will not mess with that transaction even if the Call-ID is the same.
>>
>>>Is it an update to either field ?
>>
>>I think that since multiple headers are used to define a call-leg, we
>>have a different call-leg as soon as one of them change, even if the
>>other headers (including the Call-ID) remains the same.
>>
>>>Is it a request for a new leg ? Is it erroneous. I have raised this
>>>as a seperate question on the list as it is probably a more general problem.
>>>
>>>I think it is therefore safest for the 484 to kill that call attempt and
>>>associated state completely, including within the terminating UAS that generated it. INVITES carrying the >>>subsequent digits (plus original digits) in the TO field will  then be treated as brand new call attempts >>>with no ambiguity.
>>>
>>>I am not advocating that this is the best solution, just the safest without
>>>significant change to the RFC.
>>
>>I agree. It is the safest, but not the fastest, since the gateway will
>>delete any possible information it could have used for the subsequent
>>INVITE.
> 
>I think that assuming the 484 clears down the call attempt is the best solution. The transaction is complete >when the UAS receives the ACK to this final response. The UAC that knows how to gather additional digits knows >that the call hasn't actually failed and can then issue a new INVITE with the additional digits. A UAC that >doesn't know how to gather additional digits assumes that the call has failed. This is not much different from >behavior on receiving 401 response. The UAC gathers more information (username and password) and issues a new >INVITE to complete the call.

One problem with this approach, though, is that you must implement
buffering of digits. The PSTN side can provide you the digits very fast,
and you will have to store them somewhere in the SIP part of your
implementation until you have received the 484 and sent the ACK. And,
what do you do with the buffered digits if you, for some reason, receive
a non-484 responses (3xx, for example, or even a 2xx).

This is also a problem (maybe even bigger) in ISUP transparency, where
you may want to sent subsequent ISUP messages before you receive a final
response to the INVITE. The solution was to allow INFO request before
you receive the final response to the INVITE. However, in that case the
specific SIP part of the call is not affected, which it is in the
operlap sending case, so I don't think INFO is a solution here.

Regards,

Christer Holmberg
Ericsson Finland




> 
> >
> >
> > >As I said previously, I believe a better solution would be to able to send
> > >re-INVITES after an infomational response, but before the final ACK. Of course, this would mean the TO field >has to remain consistent for all these re-INVITES so could not be used to carry the subsequent digits.........
> >
> > I agree. In that case I guess we would need a separate header, or a new
> > To header parameter, to transport the subsequent digits.
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> > >Advive on this matter from the SIP authors would be gratefully appreciated.
> >
> > > Regards,
> > >
> > > K. Robinson.
> > >
> > > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 09/01/2001 10:50:06
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >  To:      sip@lists.bell-labs.com
> > >
> > >  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
> > >           <stlevy@cisco.com>
> > >
> > >
> > >
> > >  Subject: Re: [SIP] Overlap Sending
> > >
> > >
> > > Hi,
> > >
> > > >I take your point about requiring a proxy to route 6543231@sipgw.com the same
> > > >way as 65432@sipgw.com but I believe this to be entirely within the routing
> > > data
> > > >set up by the administration. Allowing clients to choose there own path through
> > > the
> > > >network to get to their desired destination using various digit sequences seems
> > > like the
> > > >classic way of exposing networks to fraudulent use (billing avoidance,
> > > bypassing security,
> > > >etc). However, I think this is a seperate issue.
> > >
> > > Well, it's related :)
> > >
> > > >I am still concerned about the Route header overwriting the R-URI and therefore
> > > >destroying the subsequent digits when subsequent messages are routed using the
> > > Route header mechanism. I
> > > >am not sure that putting the subsequent digits in the TO header helps because I
> > > believe the TO
> > > >URL is supposed to be invariant during the lifetime of the call leg.
> > >
> > > Well, this depends a little on how you define a call leg, I guess...
> > > Since you got a 4xx response to your first INVITE, you didn't manage to
> > > set up a call leg, so then you try to set up a "new" call leg - with a
> > > new R-URI and To header...
> > >
> > > INVITE 123@sipgw.com
> > > To: 123@sipgw.com
> > >
> > > <---- 484 -----
> > >
> > > INVITE 123456@sipgw.com
> > > To: 123456@sipgw.com
> > >
> > > >Modifying the TO URL after the initial INVITE I think will cause problems for
> > > proxies  that are using the TO >URL to match subsequent requests to call legs in
> > > progress.
> > >
> > > Since the proxy sent back 484, I wouldn't consider the call leg to be in
> > > progress anymore (after the proxy receive the ACK, that is).
> > >
> > > And, the proxy will probably have to do the routing based on the To
> > > header, since the R-URI will probably (unless we use an outbound proxy)
> > > be the address of the proxy itself, so if the To header isn't changed
> > > the proxy will try to route 123@sipgw.com every time, even if more
> > > digits have provided by the client. And, if the proxy is supposed to
> > > "combine" the Current-Dial-String header value with the To header, to be
> > > able to route, I think that the client could put the new value in the To
> > > header from the beginning. Because, if the proxy doesn't support the
> > > Current-Dial-String it wouldn't be able to do anything, since both the
> > > R-URI and To header could be the same in the subsequent INVITEs. If you
> > > have a updated To header, and the proxy doesn't support the digitmap, it
> > > would at least be able to route the new To header - even if the message
> > > may take a "wrong" route.
> > >
> > > >Without introducing a new header to carry the digit string, then I think the
> > > >only other way to make overlap sending work is for the 484 to clear down the
> > > call leg as other 4XX
> > > >responses do and subsequent INVITES with the original digits + additional
> > > digits to be a new INVITE (with a
> > > >new Call-Id).
> > >
> > > I agree, but I don't think it requires a new Call-Id. Then we could
> > > still define a digitmap header to make sure  (if it is supported by the
> > > proxy) that the proxy will always route the message correctly, no matter
> > > how many INVITEs you need to provide all digits.
> > >
> > > >The initial INVITE will not be routed using Route headers, so the digit string
> > > in the R-URI will
> > > >not be lost.
> > >
> > > Proxies may change the R-URI...
> > >
> > > >There still could be a problem if the client has built a Route header (learnt
> > > out-of-band) and puts
> > > >this in the initial INVITE; the same problem may occur.
> > >
> > > This will not be a problem if all servers in the path support the
> > > digitmap... :)
> > >
> > > >Without clarification of this matter in the bis draft then I don't think
> > > overlap
> > > >sending is going to be interoperable.
> > >
> > > I agree.
> > >
> > > Personally I think (no, this is NOT a proposal to re-write SIP :) the
> > > best way would be to have some kind of "multi-message" setup, and that
> > > would also solve a number of other issues (i.e. ISUP transparency).
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > > Keith Robinson wrote:
> > > >
> > > > Let's consider the following point:
> > > >
> > > > "I don't know. I haven't seen a proxy that would route depending on the
> > > > user, but it COULD happend. Let's assume , for example, that you do a
> > > > SRV DNS lookup, and get a list of servers. Then you MAY choose a
> > > > different server, for load balance purpose e.g., depending on the user
> > > > name. Just an example..."
> > > >
> > > > One way of ensuring that subsequent requests always traverse a given SIP
> > > > node is for that node to Record-Route or supply a Contact ; it is likely that
> > > > proxies and
> > > > UAS at PSTN interworking points will require to stay in the signalling path
> > > > during
> > > > call setup so will do so.  Now, suppose one such node receives an initial
> > > INVITE
> > > > with
> > > > a R-URI of sip:654@sipgw.com and creates a Contact header thus:
> > > >
> > > > Contact: sip:654@sipgw.com;maddr=sipgw.com
> > > >
> > > > This is then returned in the 484 response so that the sending UA may build a
> > > > Route header from it. Here is my first concern; will the sending UA treat the
> > > > subsequent INVITE as a subsequent INVITE or as a new INVITE on a new
> > > > Call-Id ? I ask because the 484 response is non-200 final response which
> > > > implies that that call attempt has failed; obviously in this case it hasn't
> > > > failed
> > > > (not yet, anyway) its just been partially set up.  Does this lead to special
> > > > case handling
> > > > for a particular 4XX response ? In fact, the 484 is almost like an
> > > informational
> > > > response.
> > > > Would it be better to send an informational response (say 183) and the spec
> > > > updated to
> > > > allow subsequent INVITEs to be sent before the final ACK (a point raised by J.
> > > > Rosenberg
> > > > earlier on the list, but in a different context - to convey updated SDP
> > > > information).
> > > >
> > > > Assuming the above is resolved one way or another, then a SIP node preceding
> > > > sipgw.com is going to receive a subsequent INVITE for this call (containing
> > > > additional
> > > > digits 321)  that will look something like:
> > > >
> > > > INVITE sip:321@preceding.sipgw.com
> > > > Route: sip:654@sipgw.com;maddr=sipgw.com
> > > >
> > > > As a Route header is present, this will be used to route the INVITE so
> > > > therefore sipgw.com will receive an INVITE with the following Request
> > > > Line:
> > > >
> > > > INVITE sip:654@sipgw.com;maddr=sipgw.com
> > > >
> > > > And here is a more worrying problem, the subsequent digits have been lost.
> > > > The situation would be no better if the subsequent INVITE contained original
> > > > digits
> > > > plus subsequent digits; they would still be lost.
> > > >
> > > > The problem stems from the fact that the R-URI is supposed to be invariant at
> > > > each
> > > > node during the lifetime of the call leg, yet to do overlap sending it is
> > > being
> > > > used to
> > > > convey new information so therefore does not remain invariant and other parts
> > > of
> > > > the
> > > > protocol which assume it is invariant e.g., routing using the Route header
> > > > break.
> > > >
> > > > Using a TEL URL does not help either; the digits would still be lost after the
> > > > popping of
> > > > the Route entry into the R-URI.
> > > >
> > > > It would be easier to implement overlap sending if a seperate header could be
> > > > used to
> > > > convey the dialled digits, so an original INVITE may look something like:
> > > >
> > > > INVITE sip:digitdecode@sipgw.com
> > > > Current-Dial-String: 01623
> > > >
> > > > The subsequent INVITES would then look something like:
> > > >
> > > > INVITE sip:digitdecode@sipgw.com;maddr=sipgw.com
> > > > Current-Dial-String: 01623654398
> > > >
> > > > This ties in with your point of implementing a digit map header.
> > > >
> > > > Regards,
> > > >
> > > > K. Robinson.
> > > >
> > > > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 13:40:47
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >  To:      sip@lists.bell-labs.com
> > > >
> > > >  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
> > > >           <stlevy@cisco.com>
> > > >
> > > >
> > > >
> > > >  Subject: Re: [SIP] Overlap Sending
> > > >
> > > >
> > > > Hi,
> > > >
> > > > >If a proxy, not serving uas.com, receives an INVITE with a R-URI of
> > > 4@uas.com,
> > > > >why would it route it differently (Route headers not withstanding) from an
> > > > INVITE
> > > > >with a R-URI of 441@uas.com ?
> > > >
> > > > I don't know. I haven't seen a proxy that would route depending on the
> > > > user, but it COULD happend. Let's assume , for example, that you do a
> > > > SRV DNS lookup, and get a list of servers. Then you MAY choose a
> > > > different server, for load balance purpose e.g., depending on the user
> > > > name. Just an example...
> > > >
> > > > And, what happen if you use a TEL-URL, where you have to route depending
> > > > on the user name (=telephone number). I guess using a ENUM DNS lookup
> > > > COULD route it to the same host, but then I guess you would have to
> > > > configure your DNS to for all the possible combinations (4.e164.arpa,
> > > > 44.e164.arpa and 441.e164.arpa)...
> > > >
> > > > >Surely, if the proxy does not serve the domain identified in the R-URI it
> > > > cannot
> > > > >make any routing decisions based on the user part of the R-URI.
> > > > >If, on the other hand, the proxy does serve uas.com, then it will be involved
> > > > in
> > > > >routing the call using the dialled digit string and I would expect it to know
> > > > such things as minimum digits to
> > > > >translation and perhaps even maximum number of digits to follow. Also,
> > > because
> > > > the proxy is doing digit based
> > > > >routing it must be subject to the requirements of overlap sending so I would
> > > > expect it to be stateful, at >least until call setup is complete, in which
> > > case
> > > > remembering previous call information would be reasonable. >In fact, such a
> > > > proxy appears much like the interworking UAs I referred to previously and to
> > > > which my question >applies.
> > > >
> > > > That was my point - that you also have to have support for this in your
> > > > proxies, and not only in your client.
> > > >
> > > > I think the issue is that there are lots of what-ifs involved in this,
> > > > and it should be specified how the specific cases are handled -
> > > > especially by proxies and redirect servers.
> > > >
> > > > Regards,
> > > >
> > > > Christer Holmberg
> > > > Ericsson Finland
> > > >
> > > > > Regards,
> > > > >
> > > > > K. Robinson
> > > > >
> > > > > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > Keith Robinson wrote:
> > > > >
> > > > > If a proxy, not serving uas.com, receives an INVITE with a R-URI of
> > > 4@uas.com,
> > > > > why
> > > > > would it route it differently (Route headers not withstanding) from an
> > > INVITE
> > > > > with a R-URI of 441@uas.com ?
> > > > > Surely, if the proxy does not serve the domain identified in the R-URI it
> > > > cannot
> > > > > make any
> > > > > routing decisions based on the user part of the R-URI.
> > > > >
> > > > > If, on the other hand, the proxy does serve uas.com, then it will be
> > > involved
> > > > in
> > > > > routing the call using the dialled
> > > > > digit string and I would expect it to know such things as minimum digits to
> > > > > translation and perhaps even
> > > > > maximum number of digits to follow. Also, because the proxy is doing digit
> > > > based
> > > > > routing it must be subject to the
> > > > > requirements of overlap sending so I would expect it to be stateful, at
> > > least
> > > > > until call setup is complete, in which
> > > > > case remembering previous call information would be reasonable. In fact,
> > > such
> > > > a
> > > > > proxy appears much like the
> > > > > interworking UAs I referred to previously and to which my question applies.
> > > > >
> > > > > Regards,
> > > > >
> > > > > K. Robinson
> > > > >
> > > > > Christer Holmberg <christer.holmberg@lmf.ericsson.se> on 08/01/2001 10:43:36
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >  To:      sip@lists.bell-labs.com
> > > > >
> > > > >  cc:      Keith Robinson/MAIN/MC1@MCMAIN, Steve Levy
> > > > >           <stlevy@cisco.com>
> > > > >
> > > > >
> > > > >
> > > > >  Subject: Re: [SIP] Overlap Sending
> > > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I think sending re-INVITES containing only subsequent digits will create
> > > > > some problems. It's not enough that the UAS remembers the previous
> > > > > INVITEs for the specific Call-ID, you may also have intermediate
> > > > > redirect- and/or proxy servers that make their redirect/forwarding
> > > > > decissions based on the destination number, and then they would also
> > > > > have to remember the previous INVITEs, and they would possible also have
> > > > > to be able to know if, and in some cases, how many digits will follow
> > > > > (e.g. 4@uas.com may be routed to a complete destination than
> > > > > 441@uas.com, etc.) Maybe we should implement some kind of digit-map
> > > > > header, or something... :)
> > > > >
> > > > > Regards,
> > > > >
> > > > > Christer Holmberg
> > > > > Ericsson Finland
> > > > >
> > > > > Keith Robinson wrote:
> > > > > >
> > > > > > Yes, this is the type of case I have in mind. The question I have is what
> > > > are
> > > > > > the subsequent INVITES; are they
> > > > > >
> > > > > > a) New INVITES, on a new Call-Id containing the original digits (from
> > > > original
> > > > > > INVITE) + subsequent digits ?
> > > > > >
> > > > > > or
> > > > > >
> > > > > > b) re-INVITES containing only subsequent digits ?
> > > > > >
> > > > > > or
> > > > > >
> > > > > > c) re-INVITES containing original digits + subsequent digits ?
> > > > > >
> > > > > > The sending UAs I referred to in my previous note are those that sit in
> > > > > PSTN/SIP
> > > > > > gateways,
> > > > > > not necessarily an originating UA sitting on someones desktop.
> > > > > >
> > > > > > So, the question applies as much to these interworking UAs for
> > > constructing
> > > > > > the subsequent INVITEs as well as to receiving UAs for interpreting them.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > K. Robinson.
> > > > > >
> > > > > > Steve Levy <stlevy@cisco.com> on 05/01/2001 22:32:00
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >  To:      Keith Robinson/MAIN/MC1@MCMAIN,
> > > > > >           sip@lists.bell-labs.com
> > > > > >
> > > > > >  cc:
> > > > > >
> > > > > >
> > > > > >
> > > > > >  Subject: Re: [SIP] Overlap Sending
> > > > > >
> > > > > >
> > > > > > Hi Keith,
> > > > > >
> > > > > > I was wondering if in considering overlap sending issues and SIP if you
> > > were
> > > > > > considering the case of overlap sending across multiple networks with
> > > > variable
> > > > > > length digits.
> > > > > >
> > > > > > In this case, in order to avoid post dial delay, the digits need to be
> > > > passed
> > > > > > through the networks to the final destiantion network prior to end of dial
> > > > > > (since the destination network is the only network that knows how many
> > > > digits
> > > > > > are required). So in effect there may be additional digits sent after an
> > > > > INVITE
> > > > > > has been received and sent downstream to the callee.
> > > > > >
> > > > > > Thanks,
> > > > > > Steve
> > > > > >
> > > > > > At 03:50 PM 1/5/01 +0000, Keith Robinson wrote:
> > > > > > >
> > > > > > >
> > > > > > >I have the following query regarding overlap sending as defined in
> > > > > > >rfc2543bis-02:
> > > > > > >
> > > > > > >Section 4.2.1 states the following:
> > > > > > >
> > > > > > >"...the UAS compares the Request-URI with Request-URI of the previous
> > > > INVITE
> > > > > > >request
> > > > > > >for the same Call-Id. If the Request-URI  contains additional digits in
> > > the
> > > > > > >'user' part, the UAS
> > > > > > >treats the INVITE as adding additional digits to the original dialed
> > > > string."
> > > > > > >
> > > > > > >This appears to imply that the subsequent INVITE contains the original
> > > > > dialled
> > > > > > >string plus the
> > > > > > >additional digits; if this is the case, then there is no need for the UAS
> > > > to
> > > > > > >remember the
> > > > > > >previous string, and therefore no need to keep any state regarding the
> > > > > previous
> > > > > > >attempt.
> > > > > > >The subsequent INVITE can really be a new INVITE., i.e. a new Call-Id.
> > > > > > >
> > > > > > >If, on the other hand, the sending UA only sends additional digits, then
> > > > the
> > > > > > >original digits
> > > > > > >will have to be remembered by the UAS, and the INVITE matched up with
> > > this
> > > > > > >state
> > > > > > >so
> > > > > > >this INVITE must be on the same Call-Id.
> > > > > > >
> > > > > > >This latter case is similar to the way existing telephony protocols
> > > > transmit
> > > > > > >addtional digits
> > > > > > >when doing overlap sending.
> > > > > > >
> > > > > > >So, upon receiving a response of 484 Address Incomplete, does the sending
> > > > UA
> > > > > > >send
> > > > > > >original digits plus aditional digits on a new Call-Id or additional
> > > digits
> > > > > > >only
> > > > > > >on the same
> > > > > > >Call-Id with an incremented Cseq.
> > > > > > >
> > > > > > >Regards,
> > > > > > >
> > > > > > >K. Robinson.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >_______________________________________________
> > > > > > >SIP mailing list
> > > > > > >SIP@lists.bell-labs.com
> > > > > > >http://lists.bell-labs.com/mailman/listinfo/sip
> > > > > >
> > > > > > _______________________________________________
> > > > > > SIP mailing list
> > > > > > SIP@lists.bell-labs.com
> > > > > > http://lists.bell-labs.com/mailman/listinfo/sip
> > > > > >
> > > > > > _______________________________________________
> > > > > > SIP mailing list
> > > > > > SIP@lists.bell-labs.com
> > > > > > http://lists.bell-labs.com/mailman/listinfo/sip
--------------95D56C423D7C2FC0AA914F17
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------95D56C423D7C2FC0AA914F17--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 04:20:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27891
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 04:20:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 926F944366; Thu, 11 Jan 2001 03:19:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id AAAAA44362
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 03:18:20 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 11 Jan 2001 09:18:09 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id JAA25871; Thu, 11 Jan 2001 09:16:52 GMT
From: "Jo Hornsby" <jhornsby@ubiquity.net>
To: <Jin-Gen.Wang@Level3.com>, <sip@lists.bell-labs.com>
Subject: RE: [SIP] questions on stateless vs. stateful proxy
Message-ID: <000401c07baf$3c2d7840$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <350829A9DA9FD411841200508BF9F0600C617A@n0217idc1.oss.level3.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 09:16:52 -0000
Content-Transfer-Encoding: 7bit

> I have two questions on the concept of stateless vs stateful
> proxy. Based on
> my reading of RFC2543bis-02 and FAQ on www.cs.columbia.edu, state in
> stateful/stateless proxy refers to a transaction state. A call can consist
> of multiple SIP transactions. So,
>
> (1) A stateful vs stateless proxy should be understood on a transaction
> by transaction basis. Am I correct?

Yup.

> (2) A physical proxy can act as a stateful proxy for some transactions
> within a call, and as a stateless proxy for some other transactions within
> the same call. Am I correct?

Yup.

> (Quota from FAQ: "These are also logical
> entities; a physical proxy is likely to act as a stateless proxy for some
> calls, stateful for others, and as a redirect server for even
> others." Here
> it only mentions calls instead of transactions.)

Hmmm...using the word "calls" here (instead of "transactions") is
perhaps a little unfortunate.  It's not wrong, of course, but
"transactions" would have been more explicit.

HTH,


 - Jo.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 05:29:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28280
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 05:29:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4527644337; Thu, 11 Jan 2001 04:30:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb6.rediffmail.com (unknown [202.54.124.151])
	by lists.bell-labs.com (Postfix) with SMTP id 3425644336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 04:29:54 -0500 (EST)
Received: (qmail 8564 invoked by uid 510); 11 Jan 2001 10:26:10 -0000
Message-ID: <20010111102610.8563.qmail@mailweb6.rediffmail.com>
Received: from unknown (203.197.178.95) by rediffmail.com via HTTP; 11 Jan 2001 10:26:10 -0000
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
From: "Vijeth  D" <vijethd@rediffmail.com>
Content-ID: <Thu_Jan_11_15_56_09_IST_2001_0@mailweb6.rediffmail.com>
Content-type: text/plain
Content-Transfer-Encoding: 7bit
Subject: [SIP] OPTIONS method
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 11 Jan 2001 10:26:10 -0000
Content-Transfer-Encoding: 7bit

Hi,
  I just wanted to know as to what is the actual use of OPTIONS method. The capabilities of the end user will anyhow be conveyed in a 200 response to an INVITE request ( in the payload ). 



_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 05:37:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28313
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 05:37:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0244F44356; Thu, 11 Jan 2001 04:38:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id A810844354
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 04:37:11 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 11 Jan 2001 10:37:00 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id KAA29758; Thu, 11 Jan 2001 10:35:36 GMT
From: "Jo Hornsby" <jhornsby@ubiquity.net>
To: "Vijeth  D" <vijethd@rediffmail.com>, <sip@lists.bell-labs.com>
Subject: RE: [SIP] OPTIONS method
Message-ID: <000501c07bba$3c2c65d0$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
In-Reply-To: <20010111102610.8563.qmail@mailweb6.rediffmail.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 10:35:37 -0000
Content-Transfer-Encoding: 7bit

> Hi,
>   I just wanted to know as to what is the actual use of OPTIONS 
> method. The capabilities of the end user will anyhow be conveyed 
> in a 200 response to an INVITE request ( in the payload ). 

Yes, however, that implies that you've set up a session.  Also,
information is not just returned in the payload (think: Allow,
Accept.*, Supported).

OPTIONS enables querying of capabilities regardless of whether
any related session(s) exist or not.

HTH,


 - Jo.

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 05:40:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28351
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 05:40:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 364364436C; Thu, 11 Jan 2001 04:41:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.speedventures.com (unknown [212.75.74.99])
	by lists.bell-labs.com (Postfix) with ESMTP id 4406E44364
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 04:40:17 -0500 (EST)
Received: from david.david.kasujja@telia.com (212.28.214.202 [212.28.214.202]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id ZF96Y252; Thu, 11 Jan 2001 11:18:57 +0100
Message-Id: <5.0.0.25.0.20010111112012.02360e80@mail.speedventures.com>
X-Sender: speedventures/david k/david.kasujja@mail.speedventures.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
To: Sip List <sip@lists.bell-labs.com>
From: David Kasujja <david.kasujja@hotsip.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] SIP URL comparison
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 11:26:25 +0100

According to the SIP draft section 2.1: "scheme names ("sip"), domain 
names, parameter names and header names are case-insensitive, all other 
comparisons are case-sensitive."

 From my understanding this results in that the following (taking an 
example from the draft) are 3 different SIP URL's:

J.Doe@example.com, j.doe@example.com and J.DOE@example.com

My mail client doesn't differeniate between the 3 (Not sure if it follows 
the mail draft), so the question is if the comparison of the user shouldn't 
also be case insensitive and if not why?

David


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 07:27:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29104
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 07:27:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 319A144337; Thu, 11 Jan 2001 06:28:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from hindon.hss.co.in (unknown [202.54.26.202])
	by lists.bell-labs.com (Postfix) with ESMTP id 708E244336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 06:27:10 -0500 (EST)
Received: from hsssun01.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f0BCSHj14660
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 17:58:17 +0530 (IST)
Received: from sampark.hss.hns.com (sampark [139.85.229.22])
	by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id f0BCa9Y19449
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 18:06:15 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 652569D1.00448A39 ; Thu, 11 Jan 2001 17:58:38 +0530
X-Lotus-FromDomain: HSSBLR
From: mgovind@hss.hns.com
To: sip@lists.bell-labs.com
Message-ID: <652569D1.0044893E.00@sampark.hss.hns.com>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] Tel-Url query
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 17:58:35 +0530



Hello,

I have a query regarding the usage of "Tel" URLs specified in
the RFC 2806 as a part of the Addr-spec within the SIP Headers.
The ABNF for the Tel URL includes

token-char = (%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
                / %x41-5A / %x5E-7A / %x7C / %x7E)
               *(%x21-3A / %x3C-7E)

which is a part of "private-prefix". These characters include
"<", ">" among others.

Do these particular characters need to be escaped if the URL
appears as a part of the Addr-spec within a SIP header, like 'From'?

For example, if we recieve a message with
From: <tel: +3585551234567; phone-context=<fghijkl>>
Is such a From header valid?

Or should it be like:
From: <tel: +3585551234567; phone-context=%3cfghijkl%3e>

For a SIP URL, the RFC mandates that characters like "<" be escaped.
Is the same valid for Tel URLs within SIP Headers too?

Thanks in advance for your time.
Regards,
Mahesh



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 09:35:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01958
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 09:35:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A4E7744354; Thu, 11 Jan 2001 08:36:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id DAB7944336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 08:35:57 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA17191;
	Thu, 11 Jan 2001 09:35:39 -0500 (EST)
Message-ID: <3A5DC4BB.2B5C2E4F@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: David Kasujja <david.kasujja@hotsip.com>
Cc: Sip List <sip@lists.bell-labs.com>
Subject: Re: [SIP] SIP URL comparison
References: <5.0.0.25.0.20010111112012.02360e80@mail.speedventures.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 09:35:39 -0500
Content-Transfer-Encoding: 7bit

David Kasujja wrote:
> 
> According to the SIP draft section 2.1: "scheme names ("sip"), domain
> names, parameter names and header names are case-insensitive, all other
> comparisons are case-sensitive."
> 
>  From my understanding this results in that the following (taking an
> example from the draft) are 3 different SIP URL's:
> 
> J.Doe@example.com, j.doe@example.com and J.DOE@example.com
> 
> My mail client doesn't differeniate between the 3 (Not sure if it follows
> the mail draft), so the question is if the comparison of the user shouldn't
> also be case insensitive and if not why?

Before deducing proper behavior from an implementation, please consult
RFC 822 on email:

local-part  =  word *("." word)             ; uninterpreted
                                                 ; case-preserved

This does not mean that every local system has to interpret case. It may
well map JDoe into jdoe, but that is no different than a local mapping
from j.doe or j_doe or john_doe into user name doe. The latter does not
mean that the protocol treats all of these the same.

> 
> David
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 11:02:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05553
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 11:02:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E2F5944337; Thu, 11 Jan 2001 10:03:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 5B17D44336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 10:02:25 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0BG2F801740;
	Thu, 11 Jan 2001 10:02:15 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: sip-config@egroups.com
Cc: sip@lists.bell-labs.com, billy@billybiggs.com
Message-ID: <20010111100215.A29600@fdd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [SIP] draft-dean-phonectl-03.txt
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 10:02:15 -0600


A new draft of the PHONECTL protocol is available.  It has
been submitted to the IETF, but can also be obtained
from http://phonectl.sfour.com/draft-dean-phonectl-03.txt

The new draft is simpler than previous ones, has been further
abstracted from SIP.  For example a join command replaces
the kludgey hangup with Also.

The phonectl headers were also extracted from the SIP head
and now form a document type.  This helps the understanding
that phonectl is a remote operation protocol, and not
at the session layer of SIP.  Also, separation makes 
implementing in non-IP devices (such as a PDA) easier.

Please direct comments to the authors and to the sip-config
mailing list.  http://www.egroups.com/group/sip-config

--
Rick
rick_dean@3com.com


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 11:05:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05674
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 11:05:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1C3B844361; Thu, 11 Jan 2001 10:06:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from jupiter.matranortel.com (jupiter.matranortel.com [194.117.212.4])
	by lists.bell-labs.com (Postfix) with ESMTP id 90CE74435E
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 10:05:10 -0500 (EST)
Received: by jupiter.matranortel.com; id RAA02708; Thu, 11 Jan 2001 17:04:57 +0100 (CET)
Message-Id: <200101111604.RAA02708@jupiter.matranortel.com>
From: Aymeric Moizard <aymeric.moizard@matranortel.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; SunOS 5.5.1 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
References: <200101010210.DAA09033@jupiter.matranortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Question on draft-ietf-sip-100rel-02.txt
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 17:09:34 +0100
Content-Transfer-Encoding: 7bit


Hi,

The draft-ietf-sip-100rel-02.txt appears to
expire in December 2000. Is there a new
version of this one and is it on the way
to be accepted?

How do we cancel the INVITE if the UAC has
already received the 183 response. Must we
complete the PRACK "transaction" and send
"request canceled" for invite right after?

Thanks for help
Aymeric

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 11:42:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07507
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 11:42:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 98FCF44337; Thu, 11 Jan 2001 10:43:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from lara200.laratech.ca (unknown [204.191.39.254])
	by lists.bell-labs.com (Postfix) with ESMTP id 8E11144336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 10:42:27 -0500 (EST)
Received: from empowertel.com (lara38.laratech.ca [172.16.1.38])
	by lara200.laratech.ca (8.8.8+Sun/8.8.8) with ESMTP id LAA26147
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 11:41:59 -0500 (EST)
Message-ID: <3A5DE257.C7293CD7@empowertel.com>
From: Grant McSheffrey <grant.mcsheffrey@empowertel.com>
Organization: empowerTel Networks
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Sip List <sip@lists.bell-labs.com>
References: <5.0.0.25.0.20010111112012.02360e80@mail.speedventures.com> <3A5DC4BB.2B5C2E4F@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Timestamp header
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 11:41:59 -0500
Content-Transfer-Encoding: 7bit

If a client sends an INVITE request containing a Timestamp header,
should the Timestamp be echoed back in both provisional responses and
the final response, or should it only appear in the first provisional
response that is sent?

It seems to make sense that since it used to calculate timing, it is
only needed in the first response but I have a developer who seems to
think differently.

Any help greatly appreciated.

Grant McSheffrey
Test Engineer
EmpowerTel Networks


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 12:20:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09247
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 12:20:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E723C44337; Thu, 11 Jan 2001 11:21:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from is1-55.antd.nist.gov (is1-50.antd.nist.gov [129.6.50.251])
	by lists.bell-labs.com (Postfix) with ESMTP id AB76C44336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 11:20:25 -0500 (EST)
Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9])
	by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id MAA00813;
	Thu, 11 Jan 2001 12:14:39 -0500 (EST)
Message-ID: <3A5DEB4C.A4FDEFA5@nist.gov>
From: "M. Ranganathan" <mranga@nist.gov>
Reply-To: mranga@nist.gov
Organization: NIST advanced networking technologies group
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Cc: Shailendra Bhatnagar <shbhatna@cisco.com>
Subject: Re: [SIP] Syntax for To: and From: An ambiguity ?
References: <3A5CCAD3.CA34E07C@nist.gov> <3A5CCBFC.954A3CE4@cisco.com>
Content-Type: multipart/alternative;
 boundary="------------7CF4F93CA9ACCD2107295E2A"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 12:20:12 -0500


--------------7CF4F93CA9ACCD2107295E2A
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: base64

Thanks for the reply, and now here's another nitpicky question:

Is the following legal

To: sip:user@company.com;   tag=9

(notice the space between the semicolon and the tag.)  This is not a legal
SIP URL of course (sip url's have  no spaces in them) but is this a legal to
header?

Sorry for being so nitpicky.

Thanks.

Ranga.

Shailendra Bhatnagar wrote:

> >From the SIP spec :
>
> " The Contact, From and To header fields contain a URL. If the URL
>    contains a comma, question mark or semicolon, the URL MUST be
>    enclosed in angle brackets (< and >). Any URL parameters are
>    contained within these brackets. If the URL is not enclosed in angle
>    brackets, any semicolon-delimited parameters are header-parameters,
>    not URL parameters."
>
> Hope it helps.
>
> "M. Ranganathan" wrote:
> >
> > Hello!
> >
> > In the syntax for FROM and TO headers, there appears to be an ambiguity.
> > According to what I read,
> >
> > To:  sip:user@company.com;tag=9
> >
> > is valid but then  is the tag a url parameter or  part of the To
> > header?  The ambiguity can be resolved  of course  by only allowing the
> > name-addr form of the address  i.e.
> >
> > To: <sip:user@company.com>; tag = 9
> >
> > however, the RFC does not appear to require this. Am I missing something
> > here?
> >
> > Thanks
> >
> > Ranga.
> >
> > --
> > M.Ranganathan
> > NIST Advanced Networking Technologies Group,
> > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
> > Tel: 301 975 3664 Fax: 301 590 0932
> >
> > Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
Tel: 301 975 3664 Fax: 301 590 0932



--------------7CF4F93CA9ACCD2107295E2A
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
Thanks for the reply, and now here's another nitpicky question:
<p>Is the following legal
<p>To: sip:user@company.com;&nbsp;&nbsp; tag=9
<p>(notice the space between the semicolon and the tag.)&nbsp; This is
not a legal&nbsp; SIP&nbsp;URL&nbsp;of course (sip url's have&nbsp; no
spaces in them)&nbsp;but is this a legal to header?
<p>Sorry for being so nitpicky.
<p>Thanks.
<p>Ranga.
<p>Shailendra Bhatnagar wrote:
<blockquote TYPE=CITE>>From the SIP spec :
<p>" The Contact, From and To header fields contain a URL. If the URL
<br>&nbsp;&nbsp; contains a comma, question mark or semicolon, the URL
MUST be
<br>&nbsp;&nbsp; enclosed in angle brackets (&lt; and >). Any URL parameters
are
<br>&nbsp;&nbsp; contained within these brackets. If the URL is not enclosed
in angle
<br>&nbsp;&nbsp; brackets, any semicolon-delimited parameters are header-parameters,
<br>&nbsp;&nbsp; not URL parameters."
<p>Hope it helps.
<p>"M. Ranganathan" wrote:
<br>>
<br>> Hello!
<br>>
<br>> In the syntax for FROM and TO headers, there appears to be an ambiguity.
<br>> According to what I read,
<br>>
<br>> To:&nbsp; sip:user@company.com;tag=9
<br>>
<br>> is valid but then&nbsp; is the tag a url parameter or&nbsp; part
of the To
<br>> header?&nbsp; The ambiguity can be resolved&nbsp; of course&nbsp;
by only allowing the
<br>> name-addr form of the address&nbsp; i.e.
<br>>
<br>> To: &lt;sip:user@company.com>; tag = 9
<br>>
<br>> however, the RFC does not appear to require this. Am I missing something
<br>> here?
<br>>
<br>> Thanks
<br>>
<br>> Ranga.
<br>>
<br>> --
<br>> M.Ranganathan
<br>> NIST Advanced Networking Technologies Group,
<br>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
<br>> Tel: 301 975 3664 Fax: 301 590 0932
<br>>
<br>> Hf&aelig;j)b? b&sup2;&Ocirc;^>X&not;&para;&AElig;&THORN;-YZn&Ccedil;(sm&sect;&yuml;&aring;S&Euml;lm&eacute;e*&brvbar;&igrave;r?&iquest;?&uml;&yen;?&copy;&yuml;-+-Sw&egrave;&thorn;&Egrave;&copy;</blockquote>

<pre>--&nbsp;
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.&nbsp;
Tel: 301 975 3664 Fax: 301 590 0932</pre>
&nbsp;
</body>
</html>

--------------7CF4F93CA9ACCD2107295E2A--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 13:04:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11308
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 13:04:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6B2614433D; Thu, 11 Jan 2001 12:05:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 5496A44336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 12:04:55 -0500 (EST)
Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0BI44K07654;
	Thu, 11 Jan 2001 12:04:04 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f0BI0d227985;
	Thu, 11 Jan 2001 12:00:39 -0600 (CST)
Received: from ericsson.com (pc050184.exu.ericsson.se [138.85.50.184]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA14047; Thu, 11 Jan 2001 12:04:03 -0600 (CST)
Message-ID: <3A5DF584.2040406@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Grant McSheffrey <grant.mcsheffrey@empowertel.com>
Cc: Sip List <sip@lists.bell-labs.com>
Subject: Re: [SIP] Timestamp header
References: <5.0.0.25.0.20010111112012.02360e80@mail.speedventures.com> <3A5DC4BB.2B5C2E4F@cs.columbia.edu> <3A5DE257.C7293CD7@empowertel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 12:03:48 -0600
Content-Transfer-Encoding: 7bit

The timing of an IP network can naturally change over
time. If you are interested in using the Timestamp:
header, I would recommend using Timestamp: values
from all responses that you receive (with some
*intelligent* averaging mechanism).

/sean

Grant McSheffrey wrote:

> If a client sends an INVITE request containing a Timestamp header,
> should the Timestamp be echoed back in both provisional responses and
> the final response, or should it only appear in the first provisional
> response that is sent?
> 
> It seems to make sense that since it used to calculate timing, it is
> only needed in the first response but I have a developer who seems to
> think differently.
> 
> Any help greatly appreciated.
> 
> Grant McSheffrey
> Test Engineer
> EmpowerTel Networks
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 13:06:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11431
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 13:06:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A62194434A; Thu, 11 Jan 2001 12:06:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id D076944336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 12:05:20 -0500 (EST)
Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0BI56K08355;
	Thu, 11 Jan 2001 12:05:06 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f0BI56s20495;
	Thu, 11 Jan 2001 12:05:06 -0600 (CST)
Received: from ericsson.com (pc050184.exu.ericsson.se [138.85.50.184]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA14078; Thu, 11 Jan 2001 12:05:05 -0600 (CST)
Message-ID: <3A5DF5C2.3070404@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: mranga@nist.gov
Cc: sip@lists.bell-labs.com, Shailendra Bhatnagar <shbhatna@cisco.com>
Subject: Re: [SIP] Syntax for To: and From: An ambiguity ?
References: <3A5CCAD3.CA34E07C@nist.gov> <3A5CCBFC.954A3CE4@cisco.com> <3A5DEB4C.A4FDEFA5@nist.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 12:04:50 -0600
Content-Transfer-Encoding: 8bit

Yes, this is perfectly legal.
/sean

M. Ranganathan wrote:

> Thanks for the reply, and now here's another nitpicky question:
> 
> Is the following legal
> 
> To: sip:user@company.com;   tag=9
> 
> (notice the space between the semicolon and the tag.)  This is not a 
> legal  SIP URL of course (sip url's have  no spaces in them) but is this 
> a legal to header?
> 
> Sorry for being so nitpicky.
> 
> Thanks.
> 
> Ranga.
> 
> Shailendra Bhatnagar wrote:
> 
>      >From the SIP spec :
>     
>     " The Contact, From and To header fields contain a URL. If the URL
>        contains a comma, question mark or semicolon, the URL MUST be
>        enclosed in angle brackets (< and >). Any URL parameters are
>        contained within these brackets. If the URL is not enclosed in angle
>        brackets, any semicolon-delimited parameters are header-parameters,
>        not URL parameters."
>     
>     Hope it helps.
>     
>     "M. Ranganathan" wrote:
>      >
>      > Hello!
>      >
>      > In the syntax for FROM and TO headers, there appears to be an 
>     ambiguity.
>      > According to what I read,
>      >
>      > To:  sip:user@company.com;tag=9
>      >
>      > is valid but then  is the tag a url parameter or  part of the To
>      > header?  The ambiguity can be resolved  of course  by only 
>     allowing the
>      > name-addr form of the address  i.e.
>      >
>      > To: <sip:user@company.com>; tag = 9
>      >
>      > however, the RFC does not appear to require this. Am I missing 
>     something
>      > here?
>      >
>      > Thanks
>      >
>      > Ranga.
>      >
>      > --
>      > M.Ranganathan
>      > NIST Advanced Networking Technologies Group,
>      > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899.
>      > Tel: 301 975 3664 Fax: 301 590 0932
>      >
>      > Hfæj)b? b²Ô^>X¬¶ÆÞ-YZnÇ(sm§ÿåSËlmée*¦ìr?¿?¨¥?©ÿ-+-SwèþÈ©
>     
> -- 
> M.Ranganathan
> NIST Advanced Networking Technologies Group,
> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
> Tel: 301 975 3664 Fax: 301 590 0932
>  


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 14:10:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12689
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 14:10:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 82B654433A; Thu, 11 Jan 2001 13:11:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from aurora.tsm.es (unknown [194.224.100.20])
	by lists.bell-labs.com (Postfix) with ESMTP id B535E44336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 02:26:32 -0500 (EST)
Received: by aurora.tsm.es; (8.8.8/1.3/10May95) id JAA28498; Thu, 11 Jan 2001 09:26:18 +0100 (MET)
From: <Javier_Ferreiro_Garcia/UT03329/PLATAFORMAS_DE_SERVICIOS/TSM%TSM@tsm.es>
Subject: Re: [SIP] SIP & 3GPP
To: Krishna.Sai@jax.ecitele.com
Cc: Jack Yu <jyu@arc.corp.mot.com>, sip@lists.bell-labs.com
Message-ID: <OFA135FD78.F1E595C6-ONC12569D1.002CAB2E@tsm.es>
X-MIMETrack: Serialize by Router on abantos/TSM(
 =?iso-8859-1?q?Versi=F3n_5=2E0=2E5_|Octubre_21=2C_2000=29_at_11=2F01=2F?=
 =?us-ascii?q?2001?= 09:23:51 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 09:23:49 +0100


A couple of old links related to SIP architecture in 3GPP:
http://www.3gpp.org/ftp/Specs/2000-06/R2000/23_series/23821-101.zip (note
this is a Technical Report related to the R00, currently splitted into R4
and R5)
http://www.cs.columbia.edu/~hgs/sip/talks/SIP3GPP.ppt

Btw, Jack, are 3G TS 24.228 and 3G TS 24.229 publicly available somewhere?
I just got 24.228 v 010 on the 3gpp site.



-----------------------------< O >-----------------------------------
Javier Ferreiro Garcia
Consultant
Telefonica Moviles
Dpto. de Plataformas de Servicios
3rd Generation Intelligent Network Platforms
    Telf.: +34 630 00 43 13
-----------------------------< O >-----------------------------------


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 14:12:18 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12726
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 14:12:16 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F0FF344348; Thu, 11 Jan 2001 13:11:17 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by lists.bell-labs.com (Postfix) with ESMTP id A956944336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 10:43:30 -0500 (EST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id IAA11862;
	Thu, 11 Jan 2001 08:38:55 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA22575; Thu, 11 Jan 2001 08:38:55 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14941.57759.495616.74992@thomasm-u1.cisco.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Michael Thomas'" <mat@cisco.com>,
        "'Christian Huitema'" <huitema@exchange.microsoft.com>,
        Henning Schulzrinne <hgs@cs.columbia.edu>, sip@lists.bell-labs.com
Subject: RE: [SIP] new record-route text!
In-Reply-To: <B65B4F8437968F488A01A940B21982BF9AB01B@DYN-EXCH-001.dynamicsoft.com>
References: <B65B4F8437968F488A01A940B21982BF9AB01B@DYN-EXCH-001.dynamicsoft.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 08:38:55 -0800 (PST)
Content-Transfer-Encoding: 7bit


Jonathan, I think you were misreading the spirit of my post.
Read on...

Jonathan Rosenberg writes:
 > > From: Michael Thomas [mailto:mat@cisco.com]
 > > I respect your desire to get this to play as well
 > > as to be expected with fog machines, but if it
 > > comes at the cost of making a mess out of a clear,
 > > sunny net I have serious problems. Assuming you
 > > haven't already drank the kool-aid, let's be
 > > careful here; record route is a sometimes useful,
 > > but unwieldy and unreliable tool which should be
 > > used as little as possible. The preface text of
 > > RR ought to be "If you think you need it, you
 > > probably don't. Think again."
 > 
 > I just don't agree with that. If thats the case, boy 
 > have we been wasting a lot of time specifying and testing
 > it at bakeoffs. 
 > 
 > Record route serves many useful functions; functions that
 > user agents will want to get from proxy servers. They are critical
 > for call features (such as those provided by sip cgi, cpl, servlets, etc.),
 > security functions of all sorts, including but not limited to firewall
 > traversal,

   I'm not sure what you mean by security functions. As
   I posted earlier, if you mean things that require the
   proxy to open and close something that doesn't actually
   pass through it (like, say, media) you already have to
   deal with soft-state elsewhere. At the least, record 
   route is adding extra hops that soft-state could 
   probably reap, and at worst, it might be (perhaps
   mistakenly) adding soft state to your proxy as well.

 > Record routing is the ultimate in flexibility.

   Sure. I'm not saying to nuke it.

 > If you make record-route support in a UA optional, 

   No, I don't think that's what I was saying. I am interested
   in Christian's escape-hatch idea though. I read that as a
   "I implement it and thanks but no thanks" kind of proposal.

 > People also know that I'm a big fan of new applications enabled by sip. Fact
 > is, some of these applications live in servers in the network. Many of these
 > won't work if proxies can't see all signaling for the call. I'm afraid that
 > we will literally destroy sips ability to provide services if we don't
 > ensure that record route functions properly. I do not think the answer
 > should be "use a B2BUA for all of these". There is a big cost difference in
 > having a B2BUA process calls as compared to a proxy, and there are also
 > security issues that arise. B2BUA is applicable in some cases, to be
 > certain, but not in EVERY case where we want call state aware processing in
 > the network.

   The dividing line, IMO, is whether you *require* knowledge of
   the end of the session -- especially if it may be in the UA's
   advantage to "forget" to proxy route the BYE.

 > The burden of record-route support in UA is small. You need to store the
 > record-route list and reuse it for subsequent requests. Its not a big deal. 

   The controversy, such as it is, is not whether the few lines
   of code are a problem on the UA. The problem that I see with
   RR is much more in the domain of gratuituously adding state
   and unneeded routing to proxies, and increasing the complexity
   and single points of failure to the system. Without RR, 
   fate sharing is the minimum: the parties of the session.
   I also worry a little about traffic analysis through parties
   that want to glean more information about your call than
   the bare necessity and hand it over to people who shouldn't
   be getting it (= feds, spammers...). 

   For these reasons, I think that RR should be discouraged 
   unless there really, really isn't any other way to perform
   the function you need. Not deprecated, not not standardized,
   but just listed with a bunch of "CAUTION:"'s.

		   Mike

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 14:13:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12757
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 14:13:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C64FC44355; Thu, 11 Jan 2001 13:11:29 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by lists.bell-labs.com (Postfix) with ESMTP id 131CE44336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 11:33:22 -0500 (EST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id JAA13056;
	Thu, 11 Jan 2001 09:33:00 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA22589; Thu, 11 Jan 2001 09:33:00 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14941.61004.536178.839707@thomasm-u1.cisco.com>
To: "Christian Huitema" <huitema@exchange.microsoft.com>
Cc: "Rick Dean" <siplist@fdd.com>,
        "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>,
        <sip@lists.bell-labs.com>
Subject: RE: [SIP] Early media replacement.
In-Reply-To: <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9ED@speak.dogfood>
References: <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9ED@speak.dogfood>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 09:33:00 -0800 (PST)
Content-Transfer-Encoding: 7bit

Christian Huitema writes:
 > The third argument is that it is in some cases nice to start a two-ways
 > session without actually starting to bill the call. That one is, IMHO,
 > bogus. If one wants to provide billing indications, one should do so
 > by carrying explicit "start of billing" marks. One possibility could
 > be to answer the call with a 200 OK, maybe with a special header that
 > says "the call is set temporarily, don't bill yet," and rely on an INFO
 > message or maybe a subsequent re-invite to actually start billing. In
 > any case, all procedures that allow for a two-way session without 
 > billing provide an opening for fraud.

   Actually, I have a lot of doubts that this belongs in
   the call signaling plane at all for this very reason.
   If the UA's are trustworthy, they can just send the 
   accounting messages themselves. If they are not and there
   are no policers at the edge of the trust
   boundary to police the session, then nothing can be
   done. The policing is generally of the QoS flow variety
   at edge routers for RTP, but more generally one shouldn't
   expect that the session and signaling plane have any
   necessary connection with one another. As such, I think
   that any reliable accounting messages must to be placed
   at a trustworthy device where the actual
   session flows through so that it can reliably
   determine the beginning and end of the session.

		 Mike

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 14:15:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12790
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 14:15:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 64F964435B; Thu, 11 Jan 2001 13:11:37 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id EDF0E44336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 13:06:28 -0500 (EST)
Received: from diamond.cs.columbia.edu (diamond.cs.columbia.edu [128.59.16.9])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA10041
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 14:06:17 -0500 (EST)
Received: (from petkos@localhost)
	by diamond.cs.columbia.edu (8.9.3/8.9.3) id OAA11716
	for sip@lists.bell-labs.com; Thu, 11 Jan 2001 14:06:16 -0500 (EST)
From: "Petri K. Koskelainen" <petkos@cs.columbia.edu>
Message-Id: <200101111906.OAA11716@diamond.cs.columbia.edu>
To: sip@lists.bell-labs.com
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: Regarding Multiple Content Types
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 14:06:16 -0500 (EST)
Content-Transfer-Encoding: 7bit


Hi,

> I have a question about sending a Message body 
> with a Request/Response. Can I send a Message body 
> with more than one Content Type..
> for eg. with the Invite request I might want to 
> send some text/pic along with the SDP parameters. 
> 


Yes.
Use MIME multipart as the content type.
(which may include several content types).

This is a standard feature and supported
probably by all decent SIP implementations.


--
Petri

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 14:45:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13348
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 14:45:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E79784433C; Thu, 11 Jan 2001 13:46:03 -0500 (EST)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id C3AD24433A
	for <sip@share.research.bell-labs.com>; Thu, 11 Jan 2001 13:45:32 -0500 (EST)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Jan 11 14:43:55 EST 2001
Received: by lists.bell-labs.com (Postfix)
	id 6EB9544380; Thu, 11 Jan 2001 14:32:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5])
	by lists.bell-labs.com (Postfix) with SMTP id 1E4974437D
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 14:32:03 -0500 (EST)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id NAA21105; Thu, 11 Jan 2001 13:31:59 -0600
Cc: sip@lists.bell-labs.com
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id NAA21081; Thu, 11 Jan 2001 13:31:57 -0600
Message-ID: <3A5E0A07.BE2B0AB4@lucent.com>
From: Vijay Gurbani <vkg@lucent.com>
Organization: Lucent Technologies/Bell Laboratories
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Thomas <mat@cisco.com>
Original-CC: sip@lists.bell-labs.com
Subject: Re: [SIP] new record-route text!
References: <B65B4F8437968F488A01A940B21982BF9AB01B@DYN-EXCH-001.dynamicsoft.com> <14941.57759.495616.74992@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 13:31:19 -0600
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:
> 
> Jonathan, I think you were misreading the spirit of my post.
> Read on...
[...]
>> People also know that I'm a big fan of new applications enabled by sip. 
>> Fact is, some of these applications live in servers in the network. Many 
>> of these won't work if proxies can't see all signaling for the call. I'm 
>> afraid that we will literally destroy sips ability to provide services if 
>> we don't ensure that record route functions properly.
> 
>    The dividing line, IMO, is whether you *require* knowledge of
>    the end of the session -- especially if it may be in the UA's
>    advantage to "forget" to proxy route the BYE.

Many services also occur mid-session; i.e. proxies may provide services
based on re-INVITEs or INFO requests as well.

>> The burden of record-route support in UA is small. You need to store the
>> record-route list and reuse it for subsequent requests. Its not a big 
>> deal.
> 
>    The controversy, such as it is, is not whether the few lines
>    of code are a problem on the UA. The problem that I see with
>    RR is much more in the domain of gratuituously adding state
>    and unneeded routing to proxies, and increasing the complexity
>    and single points of failure to the system. Without RR,
>    fate sharing is the minimum: the parties of the session.

These situations can be alleviated by judicious use of DNS; one can argue 
that response traversal based on the Via list is also a single point of 
failure, isn't it -- if a server in the Via chain crashes, the next 
downstream server will not be able to properly proxy the response to the
crashed upstream server.

In general I believe that the SIP community is aware of problems with 
*gratituous* use of R-R; but as Jonathan points out (and no one disagrees), 
R-R has its uses.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 15:21:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13858
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 15:21:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 906A04433A; Thu, 11 Jan 2001 14:22:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 9D82D44336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 14:21:30 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA14917
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 15:21:18 -0500 (EST)
Message-ID: <3A5E15BE.16C89EA5@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] SIP bake-off registration
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 15:21:18 -0500
Content-Transfer-Encoding: 7bit

Please register for the 7th SIP bakeoff at
http://www.etsi.org/bake-off/. Note that bake-off early bird
registration closes at the end of January.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 15:23:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13888
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 15:23:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6D65444359; Thu, 11 Jan 2001 14:24:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 012B244358
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 14:23:48 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0BKLDs16169;
	Thu, 11 Jan 2001 14:21:13 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: Rohan Mahy <rohan@cisco.com>
Cc: Billy Biggs <billy@billybiggs.com>,
        "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
        Sean Olson <sean.olson@ericsson.com>,
        Sip List <sip@lists.bell-labs.com>
Subject: Re: [SIP] REFER progress
Message-ID: <20010111142113.A13625@fdd.com>
References: <3A5CF2CC.CCD61470@cs.columbia.edu> <20010110130054.B12449@csclub.uwaterloo.ca> <3A5CC4D8.9050504@ericsson.com> <3A5CF2CC.CCD61470@cs.columbia.edu> <20010110185346.A981@div8.net> <5.0.0.25.2.20010110155640.01f689d0@imop.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.0.0.25.2.20010110155640.01f689d0@imop.cisco.com>; from rohan@cisco.com on Wed, Jan 10, 2001 at 04:32:59PM -0800
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 14:21:13 -0600


I don't consider it a feature, more of a contingency.
On the first try I (as the REFER sender) refer you through
your gateway.  When that fails I refer you through mine.  Next,
I back-to-back UA you to my gateway.  Firewalls of course make
this all possible.... er... I mean....  unfortunately necessary.

Needing more time is fine.  I would like us to have as many
lessons from implementation as we can before we commit ourselves.

Cheers,
Rick
Rick_dean@3com.com

On Wed, Jan 10, 2001 at 04:32:59PM -0800, Rohan Mahy wrote:
> Hi,
> 
> We need to go back to the requirements.  Callback on transfer failure is a 
> nice feature, but you and Rick seem to be assuming that this feature is 
> common enough to merit special optimizations.  I'm not convinced.  Maybe we 
> will decide the proposed optimization (Event header in any method) is 
> useful and simple or benign enough to make it a standard, but let everyone 
> see the complete picture before we decide.
> 
> thanks,
> -rohan
> 
> 
> 
> 
> At 03:53 PM 1/10/01, Billy Biggs wrote:
> >Henning G. Schulzrinne (hgs@cs.columbia.edu):
> >
> > > Generally, I think 'hold' is a poor UI choice for longer-duration
> > > interruptions.
> >
> >   The line would likely "disappear" from the UI or be hidden or
> >something.  The re-INVITE after failure would then cause the phone to
> >ring as if it was an incoming call.
> >
> > > (Also, note that the In-Reply-To header can provide hints that this is
> > > "return engagement" has a relationship with an older call. The UI is
> > > then free to do something special if desired.)
> >
> >   We want to use the existing session, re-INVITE rather than a new
> >INVITE, in order to avoid forking and make recovery reliable.
> >
> > > > However, if you really want this then:
> > > >
> > > > 1) The transferor sends a REFER without a Refer-Notify: [...]
> > > > 2) The transferor "switches to a new line". [...]
> > > > 3) The INVITE fails for some reason ... [...]
> > > > 4) The transferee switches back to the original line [...]
> > > >
> > > > This seems a little too obvious. I must be missing a fundamental
> > > > requirement/feature of the service you are trying to build.
> > >
> > > This is basically attended transfer, right?
> >
> >   No.   Attended transfer is when a bridge excuses itself from a 3-way
> >call, connecting the two endpoints it was conversing with directly.
> >
> >--
> >Billy Biggs                     bbiggs@dumbterm.net
> >http://www.billybiggs.com/      wbiggs@uwaterloo.ca
> >
> >_______________________________________________
> >SIP mailing list
> >SIP@lists.bell-labs.com
> >http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 16:49:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15284
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 16:49:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DC5ED44337; Thu, 11 Jan 2001 15:50:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 2E9CE44336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 15:49:18 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0BLn9Q25593
	for sip@lists.bell-labs.com; Thu, 11 Jan 2001 15:49:09 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: sip@lists.bell-labs.com
Message-ID: <20010111154908.A25470@fdd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [SIP] SDP in a REFER
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 15:49:08 -0600


Hey!

I wanted to check on consensus for including SDP
in a REFER request in an connected* call-leg.
This helps to reduce the number of messages and 
the delay of processing.  It also makes some
implementations easier.  Fewer packet loss
conditions,.... blah blah blah.

*(i.e. a call-leg where an INVITE has already 
succeeded, but a BYE has not. Is there a better 
name?  I would call to-from tags assigned as
"bound" maybe "established"?  We need a linguist.) 

--
Rick
Rick_Dean@3com.com


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 18:02:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16077
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 18:02:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8981044337; Thu, 11 Jan 2001 17:03:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 98AD444336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 17:02:53 -0500 (EST)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA20517
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 15:02:52 -0800 (PST)
Received: from sony-laptop (rmahy-dsl5.cisco.com [10.19.53.126])
	by imop.cisco.com (Mirapoint)
	with SMTP id AAG95281;
	Thu, 11 Jan 2001 15:02:40 -0800 (PST)
Message-Id: <4.1.20010111145316.00ae53d0@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
To: sip@lists.bell-labs.com
From: Rohan Mahy <rohan@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [SIP] Open Issues Interim Meeting Feb 8th and 9th
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 15:08:05 -0800

Hi,

At the request of Jonathan and Brian Rosen, I'm proposing an interim
meeting of the SIP working group all day Thurs Feb 8th and Fri Feb 9th in
Dallas, Texas, USA.  I will attempt to put together a rough agenda in the
next few days.  REFER will be covered on part of the 8th.  

Lunch will be provided to those who attend, and a dial-in number (and
possibly IM) will be provided for those that want to attend but cannot
travel. All the minutes will be posted back to the list. I will post the
location and information about nearby hotels shortly.  Some folks may
choose to stay over part of the weekend to continue discussions.

thanks,
-rohan

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 18:44:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16512
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 18:44:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E469344337; Thu, 11 Jan 2001 17:45:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 8008744336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 17:44:07 -0500 (EST)
Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0BNhRK07469;
	Thu, 11 Jan 2001 17:43:27 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f0BNe2Q13254;
	Thu, 11 Jan 2001 17:40:02 -0600 (CST)
Received: from ericsson.com (b02e39 [138.85.36.139]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA00219; Thu, 11 Jan 2001 17:43:27 -0600 (CST)
Message-ID: <3A5E451E.7030905@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-21mdk i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Rick Dean <siplist@fdd.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SDP in a REFER
References: <20010111154908.A25470@fdd.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 17:43:26 -0600
Content-Transfer-Encoding: 7bit

I was under the impression that you prefer
a re-INVITE with a Refer-Status: header
or am I mistaken? (I'm happy to use a
NOTIFY instead, but as Billy pointed out there
are a number of problems with this)

/sean

Rick Dean wrote:

> Hey!
> 
> I wanted to check on consensus for including SDP
> in a REFER request in an connected* call-leg.
> This helps to reduce the number of messages and 
> the delay of processing.  It also makes some
> implementations easier.  Fewer packet loss
> conditions,.... blah blah blah.
> 
> *(i.e. a call-leg where an INVITE has already 
> succeeded, but a BYE has not. Is there a better 
> name?  I would call to-from tags assigned as
> "bound" maybe "established"?  We need a linguist.) 
> 
> --
> Rick
> Rick_Dean@3com.com
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 19:31:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16808
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 19:31:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4E5FD44338; Thu, 11 Jan 2001 18:32:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cybertron.div8.net (HSE-Kitchener-ppp194338.sympatico.ca [64.229.12.179])
	by lists.bell-labs.com (Postfix) with ESMTP id BAEEE44336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 18:31:33 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m14Gs8l-003ErKC@cybertron.div8.net> (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Thu, 11 Jan 2001 19:32:23 -0500 (EST) 
From: Billy Biggs <billy@billybiggs.com>
To: Sean Olson <sean.olson@ericsson.com>
Cc: Rick Dean <siplist@fdd.com>, SIP List <sip@lists.bell-labs.com>
Subject: Re: [SIP] SDP in a REFER
Message-ID: <20010111193223.A756@div8.net>
References: <20010111154908.A25470@fdd.com> <3A5E451E.7030905@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A5E451E.7030905@ericsson.com>; from sean.olson@ericsson.com on Thu, Jan 11, 2001 at 05:43:26PM -0600
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 19:32:23 -0500

Sean Olson (sean.olson@ericsson.com):

> I was under the impression that you prefer a re-INVITE with a
> Refer-Status: header or am I mistaken? (I'm happy to use a NOTIFY
> instead, but as Billy pointed out there are a number of problems with
> this)

  Rick is talking about SDP in the REFER, not the re-INVITE which
contains the result of the REFER.

> Rick Dean (siplist@fdd.com):
>
> > I wanted to check on consensus for including SDP in a REFER request
> > in an connected* call-leg.  This helps to reduce the number of
> > messages and the delay of processing.  It also makes some
> > implementations easier.  Fewer packet loss conditions,.... blah blah
> > blah.

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 21:24:01 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17587
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 21:24:01 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4750044344; Thu, 11 Jan 2001 20:24:11 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail15a.boca15-verio.com (unknown [208.55.91.57])
	by lists.bell-labs.com (Postfix) with SMTP id 066DE44340
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 20:23:30 -0500 (EST)
Received: from www.snowshore.com (128.241.144.247)
	by mail15a.boca15-verio.com (RS ver 1.0.58s) with SMTP id 08659752
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 21:23:01 -0500 (EST)
From: "Eric Burger" <eburger@snowshore.com>
To: <sip@lists.bell-labs.com>
Subject: RE: [SIP] SIP App Components
Message-ID: <NEBBLACLCLHMJBCAJGOEKEGACIAA.eburger@snowshore.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <B65B4F8437968F488A01A940B21982BF9AAFE9@DYN-EXCH-001.dynamicsoft.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Loop-Detect: 1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 21:23:12 -0500
Content-Transfer-Encoding: 7bit

Our concern of using a header is that proxies need to know about them at
best or not mung them at worst.  If the URL referring to the VoiceXML script
is in the body, we don't have to worry about that.

I wouldn't suggest carrying VoiceXML itself in the payload of an INVITE, as
that can be quite large.

> > -----Original Message-----
> > From: Jon.Peterson@Level3.com [mailto:Jon.Peterson@Level3.com]
> > -----Original Message-----
> > From: Eric Burger [mailto:eburger@snowshore.com]
> > Sent: Thursday, January 04, 2001 4:58 PM
> > To: sip@lists.bell-labs.com
> > Subject: [SIP] SIP App Components
> >
> >
> > The SIP App Components infrastructure assumes that the SIP
> > UA's understand
> > multipart MIME body parts.  This is a MAY in bis 02 (Section 8.2).
>
> Where in the app components document does it assume this? None of the
> interfaces require multipart. I think we might have mentioned talking to a
> voicexml media server by passing the original VoiceXML in the body of the
> SIP INVITE; however, thats only one of the options. The best one, IMHO, is
> to pass the URL for the voicexml script in a sip header (Call-Info or
> something).
>
> -Jonathan R.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Thu Jan 11 22:23:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18991
	for <sip-archive@odin.ietf.org>; Thu, 11 Jan 2001 22:23:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 340D244337; Thu, 11 Jan 2001 21:24:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by lists.bell-labs.com (Postfix) with ESMTP id 8B0FF44336
	for <sip@lists.bell-labs.com>; Thu, 11 Jan 2001 21:23:25 -0500 (EST)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id UAA16734; Thu, 11 Jan 2001 20:21:12 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id UAA24414; Thu, 11 Jan 2001 20:21:09 -0700 (MST)]
Received: from arc.corp.mot.com (ltd.arc.corp.mot.com [217.1.10.133])
	by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id f0C3HIS26305;
	Fri, 12 Jan 2001 14:17:18 +1100 (EST)
Message-ID: <3A5E7632.AD45DEB9@arc.corp.mot.com>
From: Jack Yu <jyu@arc.corp.mot.com>
Organization: Motorola Australian Research Centre
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en,zh,zh-CN,zh-TW
MIME-Version: 1.0
To: Javier_Ferreiro_Garcia/UT03329/PLATAFORMAS_DE_SERVICIOS/TSM%TSM@tsm.es
Cc: Krishna.Sai@jax.ecitele.com, sip@lists.bell-labs.com
Subject: Re: [SIP] SIP & 3GPP
References: <OFA135FD78.F1E595C6-ONC12569D1.002CAB2E@tsm.es>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 14:12:50 +1100
Content-Transfer-Encoding: 7bit


3G TS 24.228 and 3G TS 24.229 are not currently available. The work is
on-going.
You can check 3GPP TSG-N WG1 and WG1 SIP meeting document area for the
progress.
http://www.3gpp.org/ftp/TSG_CN/WG1_mm-cc-sm/
http://www.3gpp.org/ftp/TSG_CN/WG1_mm-cc-sm/SIP_meetings/

Jack

--
Zhenghua (Jack) Yu, Ph.D.
Motorola Australian Research Centre



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 02:29:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05849
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 02:29:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 91F5644337; Fri, 12 Jan 2001 01:30:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from roma.axis.se (roma.axis.se [193.13.178.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 0176544336
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 01:29:33 -0500 (EST)
Received: from klatt.axis.se (klatt.axis.se [193.13.178.133])
	by roma.axis.se (8.9.3/8.9.3) with ESMTP id IAA08824;
	Fri, 12 Jan 2001 08:29:00 +0100 (MET)
Received: by klatt.axis.se with Internet Mail Service (5.5.2653.19)
	id <CJAYNPRK>; Fri, 12 Jan 2001 08:28:54 +0100
Message-ID: <151F3D2AE9F0D3119E480004ACB8EA3701869450@cluster01.axis.se>
From: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
To: "'Sean Olson'" <sean.olson@ericsson.com>, mranga@nist.gov
Cc: sip@lists.bell-labs.com, Shailendra Bhatnagar <shbhatna@cisco.com>
Subject: RE: [SIP] Syntax for To: and From: An ambiguity ?
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 08:32:16 +0100

Actually, all of the following headers mean exactly the same
(even though the fourth version is probably the recommended
one for readability):

To: sip:user@company.com;tag=9
To: sip:user@company.com;   tag=9
To: sip:user@company.com   ;tag=9
To: <sip:user@company.com>;tag=9

I.e., as soon as we see something that is not allowed in
a URL when parsing a header (in this example a semicolon,
white space or the end angle bracket) we are done with the
URL, and continue to parse, looking for header parameters,
and then white space is of course ignored.

//Peter

> -----Original Message-----
> From: Sean Olson [mailto:sean.olson@ericsson.com]
> Sent: Thursday, January 11, 2001 19:05
> To: mranga@nist.gov
> Cc: sip@lists.bell-labs.com; Shailendra Bhatnagar
> Subject: Re: [SIP] Syntax for To: and From: An ambiguity ?
> 
> Yes, this is perfectly legal.
> /sean
> 
> M. Ranganathan wrote:
> 
> > Thanks for the reply, and now here's another nitpicky question:
> > 
> > Is the following legal
> > 
> > To: sip:user@company.com;   tag=9
> > 
> > (notice the space between the semicolon and the tag.)  This is not a 
> > legal  SIP URL of course (sip url's have  no spaces in them) but is this 
> > a legal to header?
> > 
> > Sorry for being so nitpicky.
> > 
> > Thanks.
> > 
> > Ranga.
> > 
> > Shailendra Bhatnagar wrote:
> > 
> >      >From the SIP spec :
> >     
> >     " The Contact, From and To header fields contain a URL. If the URL
> >        contains a comma, question mark or semicolon, the URL MUST be
> >        enclosed in angle brackets (< and >). Any URL parameters are
> >        contained within these brackets. If the URL is not enclosed in angle
> >        brackets, any semicolon-delimited parameters are header-parameters,
> >        not URL parameters."
> >     
> >     Hope it helps.
> >     
> >     "M. Ranganathan" wrote:
> >      >
> >      > Hello!
> >      >
> >      > In the syntax for FROM and TO headers, there appears to be an ambiguity.
> >      > According to what I read,
> >      >
> >      > To:  sip:user@company.com;tag=9
> >      >
> >      > is valid but then  is the tag a url parameter or part of the To
> >      > header?  The ambiguity can be resolved  of course  by only allowing the
> >      > name-addr form of the address  i.e.
> >      >
> >      > To: <sip:user@company.com>; tag = 9
> >      >
> >      > however, the RFC does not appear to require this. Am I missing something
> >      > here?
> >      >
> >      > Thanks
> >      >
> >      > Ranga.

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 04:51:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06615
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 04:51:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CB2604433E; Fri, 12 Jan 2001 03:52:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from aurora.tsm.es (unknown [194.224.100.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 08C8E44337
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 03:51:55 -0500 (EST)
Received: by aurora.tsm.es; (8.8.8/1.3/10May95) id KAA26486; Fri, 12 Jan 2001 10:50:33 +0100 (MET)
From: <ferreiro_j@tsm.es>
Subject: Re: [SIP] SIP & 3GPP
To: Jack Yu <jyu@arc.corp.mot.com>
Cc: Javier_Ferreiro_Garcia/UT03329/PLATAFORMAS_DE_SERVICIOS/TSM%TSM@tsm.es,
        Krishna.Sai@jax.ecitele.com, sip@lists.bell-labs.com
Message-ID: <OF1FE4FBB8.C6CD38EB-ONC12569D2.00358591@tsm.es>
X-MIMETrack: Serialize by Router on abantos/TSM(
 =?iso-8859-1?q?Versi=F3n_5=2E0=2E5_|Octubre_21=2C_2000=29_at_12=2F01=2F?=
 =?us-ascii?q?2001?= 10:48:06 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 10:48:03 +0100





>3G TS 24.228 and 3G TS 24.229 are not currently available. The work is
>on-going.

The draft version for TS24.228 I currently have is available at
http://www.3gpp.org/ftp/Specs/2000-12/Drafts/24_series/


>You can check 3GPP TSG-N WG1 and WG1 SIP meeting document area for the
>progress.
>http://www.3gpp.org/ftp/TSG_CN/WG1_mm-cc-sm/
>http://www.3gpp.org/ftp/TSG_CN/WG1_mm-cc-sm/SIP_meetings/

>Jack

--
>Zhenghua (Jack) Yu, Ph.D.
>Motorola Australian Research Centre


regards
Javier



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 08:50:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08918
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 08:50:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D38F044337; Fri, 12 Jan 2001 07:51:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from guardian1.tlv.radvision.com (unknown [212.143.185.30])
	by lists.bell-labs.com (Postfix) with ESMTP id DCDE344336
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 07:50:25 -0500 (EST)
Received: from nt-mail.tlv.radvision.com ([172.20.2.100])
          by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3
          release 223 ID# 0-0U10L2S100V35) with ESMTP id com;
          Fri, 12 Jan 2001 16:47:51 +0200
Received: by NT-MAIL with Internet Mail Service (5.5.2650.21)
	id <CZPXFLN3>; Fri, 12 Jan 2001 15:52:18 +0200
Message-ID: <E09383987EE5D3119F2E0008C7097728014D751C@NT-MAIL>
From: Itamar Gilad <ItamarG@tlv.radvision.com>
To: "'Jonathan Rosenberg'" <jdrosen@dynamicsoft.com>,
        Itamar Gilad <ItamarG@tlv.radvision.com>,
        "'SIP List'" <sip@lists.bell-labs.com>
Subject: RE: [SIP] is SIP backward compatible?
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="windows-1255"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 15:52:17 +0200



> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Tue, January 09, 2001 8:45 AM
> To: 'Itamar Gilad'; 'SIP List'
> Subject: RE: [SIP] is SIP backward compatible?
> 
> 
> 
> 
>  
> 
> 
> We've been attempting to maintain compatibility as much as 
> possible. The
> primary, but to date implicit, guideline has been that, in 
> the worse case, a
> change should cause the behavior between an rfc2543bis and 
> rfc2543 entity to
> be no different than if both were only rfc2543 compliant. In 
> other words,
> certain things are broken and/or unspecified in rfc2543. It 
> may be that the
> fix in bis will not correct the problem unless some or all of 
> the entities
> are bis compliant. I think this is a reasonable thing to do.
> 
> There is only one thing I know of that is formally not 
> backward compatible -
> the addition of extension parameters in several places. A 
> very strict parser
> might bomb on headers with extension parameters although none 
> were allowed
> according to rfc2543. Fortunately, most implementations have 
> been tracking
> the changes in the drafts, and I don't think this will be a problem in
> practice. 
> 
> If you know of anything specific that has been added or 
> changed that breaks
> backwards compatibility, please let us know.

I'm assuming this question refers to RFC2543 (March 99) vs. bis-02.  A
couple of things I'm aware of:

1) To/From tags

RFC 2543:
        tag-param    =  "tag=" UUID
        UUID         =  1*( hex | "-" )

bis-02:  
        tag-param = "tag" "=" token

2) Call-ID:  

RFC 2543:
     Call-ID   =  ( "Call-ID" | "i" ) ":" local-id "@" host
     local-id  =  1*uric
bis-02:
     callid = token [ "@" token ]
     Call-ID = ( "Call-ID" | "i" ) ":" callid

  Itamar

> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 09:03:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09145
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 09:03:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 515574433A; Fri, 12 Jan 2001 08:04:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from small-3.inet.it (unknown [212.239.0.39])
	by lists.bell-labs.com (Postfix) with ESMTP id D6BF644338
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 08:03:14 -0500 (EST)
Received: (from trusted@localhost)
	by small-3.inet.it (8.11.1/8.11.1) id f0CE31c54994
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 15:03:01 +0100
Received: from ictcons.inet.it(194.185.143.34) by small-3.inet.it via I-SMTP
	id queue/s-194.185.143.34-ZqkrUa; Fri Jan 12 15:02:54 2001
From: "Dolman Aradori" <aradori@ictc.it>
To: <sip@lists.bell-labs.com>
Message-ID: <NEBBKEHJHKAGECIOLMDHAEIACFAA.aradori@ictc.it>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Subject: [SIP] A question about SIP & 3GPP
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 15:05:44 +0100
Content-Transfer-Encoding: 7bit

Excuse me, I'm new for this list.
Could someone of you give me a pointer to the article:

Nortel Networks
"A comparison of h.323v4 and SIP"
3GPP cont.
Jan 2000	?

Thanks a lot

Dolman		

__________________

 Dolman Aradori
  Consultant

  ICT Consulting
  Via Vittor Pisani, 22
  20124 Milan 

  Phone: +39 02 67642245
  Fax: +39 0267642243
  Mobile: +39 335 7505653
 ____________________



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 10:04:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10183
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 10:04:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8B81C44338; Fri, 12 Jan 2001 09:05:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 36F4344336
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 09:04:47 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA23181;
	Fri, 12 Jan 2001 10:07:17 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ6W8MAM>; Fri, 12 Jan 2001 10:01:00 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB05E@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Rick Dean'" <siplist@fdd.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] SDP in a REFER
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 11 Jan 2001 18:07:09 -0500

To be honest, I am beginning to get annoyed here.

There is clearly not consensus. I still don't know what the problem is, and
I appear to not be alone. Instead of rambling on about SDP in REFERs and
insisting on some deep insight granted through the construction of phones, I
would strongly suggest you take a step back, and write an email or I-D that
clearly states the problem, with pictures and call flows, and clearly
explains why the proposed REFER mechanism that we have been discussing for
months and months (if not a year now) is suddenly quite wrong.

The discussions will go nowhere until we are on the same page about the
scenarios and problems to be solved.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

> -----Original Message-----
> From: Rick Dean [mailto:siplist@fdd.com]
> Sent: Thursday, January 11, 2001 4:49 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] SDP in a REFER
> 
> 
> 
> Hey!
> 
> I wanted to check on consensus for including SDP
> in a REFER request in an connected* call-leg.
> This helps to reduce the number of messages and 
> the delay of processing.  It also makes some
> implementations easier.  Fewer packet loss
> conditions,.... blah blah blah.
> 
> *(i.e. a call-leg where an INVITE has already 
> succeeded, but a BYE has not. Is there a better 
> name?  I would call to-from tags assigned as
> "bound" maybe "established"?  We need a linguist.) 
> 
> --
> Rick
> Rick_Dean@3com.com
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 10:21:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10465
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 10:21:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9B87644345; Fri, 12 Jan 2001 09:22:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18])
	by lists.bell-labs.com (Postfix) with ESMTP id 2878744342
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 01:47:52 -0500 (EST)
Received: (from jh@localhost)
	by lohi.eng.telia.fi (8.11.1/8.11.1/Debian 8.11.0-6) id f0C7ldd12123;
	Fri, 12 Jan 2001 09:47:39 +0200
From: Juha Heinanen <jh@lohi.eng.telia.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14942.46747.463192.444077@lohi.eng.telia.fi>
To: sip@lists.bell-labs.com
X-Mailer: VM 6.75 under Emacs 19.34.1
Subject: [SIP] why is contact header mandatory invites and positive responses?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 09:47:39 +0200 (EET)
Content-Transfer-Encoding: 7bit

to me it doesn't make sense that contact header is mandatory in invites
and positive responses.  

in cases where the company policy is that sip messages must go via a
given proxy (that then relays them to/from uas within the company
network), the contact header gives wrong information to the other party.
the semantics of contact header "it provides a URL where the user can be
reached for further communications" simply are not true in such a
situation.

i would not care otherwise, but i have already met three commercial sip
user agents that inspite of the record route in the messages, still send
their acks to the address in the contact header instead of that in the
record-route.

unless the contact header can't be made optional also in invites and
positive oks, i would very strongly urge that the sip bakeoffs and call
flow documents would include test cases to check the correct ua behavior
in the presense of both record-route and contact header.

-- juha

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 10:23:29 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10483
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 10:23:28 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8E5BE44345; Fri, 12 Jan 2001 09:22:18 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mip.miptel.com (unknown [210.121.191.65])
	by lists.bell-labs.com (Postfix) with ESMTP id 2D7F944337
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 03:42:00 -0500 (EST)
Received: from arnold ([210.121.191.94])
	by mip.miptel.com (8.10.1/8.8.7) with SMTP id f0C9i4u12983
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 18:44:06 +0900
From: =?ks_c_5601-1987?B?wMzI8byu?= <hslee@miptel.com>
To: <sip@lists.bell-labs.com>
Message-ID: <BPEHLGEAGAFJCAHHDKDEGEAKCDAA.hslee@miptel.com>
MIME-Version: 1.0
Content-Type: multipart/related;
	boundary="----=_NextPart_000_0003_01C07CC8.13C00A70"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Subject: [SIP] How do the proxy server search the next proxy server ?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 18:47:13 +0900

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C07CC8.13C00A70
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0004_01C07CC8.13C49E50"


------=_NextPart_001_0004_01C07CC8.13C49E50
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

DQoNCg0KcHJveHkgMSA6IHNpcC5hYWEuY29tDQpwcm94eSAyIDogc2lwLmJiYi5jb20NClVBYyA6
IGFybm9sZEBhcm5vbGQuYWFhLmNvbQ0KVUFzIDogZHJhZ29uQGRyYWdvbi5iYmIuY29tDQoNCg0K
MSkgV2hlbiBVQWMgc2VuZHMgYSByZXF1ZXN0KElOVklURSkgdG8gcHJveHkgMSwgd2hhdCBpcyB0
aGUgUmVxdWVzdC1VUkkgaW4gdGhlIFJlcXVlc3QtTGluZSA/DQogICAgKGEpIElOVklURSA6IHNp
cDpkcmFnb25Ac2lwLmJiYi5jb20NCiAgICAoYikgSU5WSVRFIDogc2lwOmRyYWdvbkBkcmFnb24u
YmJiLmNvbQ0KICAgIFdoaWNoIGlzIHRoZSBjb3JyZWN0IGFuc3dlciA/DQoNCklmIChiKSBpcyBy
aWdodCwgDQoyKSBIb3cgZG8gdGhlIHByb3h5IHNlcnZlciAxIHNlYXJjaCB0aGUgbmV4dCBwcm94
eSBzZXJ2ZXIgMj8NCg0KUGxlYXNlLCBDb3VsZCB5b3UgY29ycmVjdCBtZSA/DQpIYXBweSBuZXcg
eWVhciBhbmQgaGF2ZSBhIGdvb2QgaGVhbHRoeSEhIQ0KDQo=

------=_NextPart_001_0004_01C07CC8.13C49E50
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgY29udGVudD0idGV4dC9o
dG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxN
RVRBIGNvbnRlbnQ9Ik1TSFRNTCA1LjAwLjMxMDMuMTAwMCIgbmFtZT1HRU5FUkFUT1I+PC9IRUFE
Pg0KPEJPRFk+DQo8RElWPjxJTUcgYWxpZ249YmFzZWxpbmUgYWx0PSIiIGJvcmRlcj0wIGhzcGFj
ZT0wIA0Kc3JjPSJjaWQ6NjI3MzgzNzA5QDEyMDEyMDAxLTA2NDQiPjwvRElWPg0KPERJVj4mbmJz
cDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5wcm94eSAxIDog
c2lwLmFhYS5jb208L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5wcm94eSAyIDogc2lw
LmJiYi5jb208L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5VQWMgOiA8QSANCmhyZWY9
Im1haWx0bzphcm5vbGRAYXJub2xkLmFhYS5jb20iPmFybm9sZEBhcm5vbGQuYWFhLmNvbTwvQT48
L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48QSBocmVmPSJtYWlsdG86VUFzIDogZHJh
Z29uQGRyYWdvbi5iYmIuY29tIj48Rk9OVCANCmNvbG9yPSMwMDAwMDA+VUFzIDogPC9GT05UPmRy
YWdvbkBkcmFnb24uYmJiLmNvbTwvQT48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0K
PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjEpIFdoZW4gVUFjIHNlbmRzJm5i
c3A7YSByZXF1ZXN0KElOVklURSkgdG8gcHJveHkgMSwgd2hhdCBpcyANCnRoZSBSZXF1ZXN0LVVS
SSBpbiB0aGUgUmVxdWVzdC1MaW5lID88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsoYSkgSU5WSVRFIDogPEEgDQpocmVmPSJtYWlsdG86c2lw
OmRyYWdvbkBzaXAuYmJiLmNvbSI+c2lwOmRyYWdvbkBzaXAuYmJiLmNvbTwvQT48L0ZPTlQ+PC9E
SVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsoYikgSU5WSVRF
IDogPEEgDQpocmVmPSJtYWlsdG86c2lwOmRyYWdvbkBkcmFnb24uYmJiLmNvbSI+c2lwOmRyYWdv
bkBkcmFnb24uYmJiLmNvbTwvQT48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJz
cDsmbmJzcDsmbmJzcDsgV2hpY2ggaXMgdGhlIGNvcnJlY3QgYW5zd2VyID88L0ZPTlQ+PC9ESVY+
DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9
Mj5JZiAoYikgaXMgcmlnaHQsIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjxGT05U
IHNpemU9Mj4yKSZuYnNwO0hvdyBkbyB0aGUgcHJveHkgc2VydmVyIDEgc2VhcmNoIHRoZSBuZXh0
IA0KcHJveHkgc2VydmVyIDI/PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+
DQo8RElWPjxGT05UIHNpemU9Mj5QbGVhc2UsIENvdWxkIHlvdSBjb3JyZWN0IG1lID88L0ZPTlQ+
PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5IYXBweSBuZXcgeWVhciBhbmQgaGF2ZSBhIGdvb2Qg
aGVhbHRoeSEhITwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4N
Cg==

------=_NextPart_001_0004_01C07CC8.13C49E50--

------=_NextPart_000_0003_01C07CC8.13C00A70
Content-Type: image/jpeg;
	name="ques copy.jpg"
Content-Transfer-Encoding: base64
Content-ID: <627383709@12012001-0644>
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAgEASABIAAD/7QloUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAAR/+0AAIA
AgBH/7QAAgACOEJJTQQNAAAAAAAEAAAAeDhCSU0D8wAAAAAACAAAAAAAAAAAOEJJTQQKAAAAAAAB
AAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP0AAAAAAASADUAAAABAC0AAAAGAAAAAAABOEJJ
TQP3AAAAAAAcAAD/////////////////////////////A+gAADhCSU0EAAAAAAAAAgABOEJJTQQC
AAAAAAAEAAAAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBBQAAAAAAAQAAAACOEJJ
TQQMAAAAAAhDAAAAAQAAAHAAAAA4AAABUAAASYAAAAgnABgAAf/Y/+AAEEpGSUYAAQIBAEgASAAA
/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwR
DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwR
EQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAOABwAwEiAAIRAQMRAf/d
AAQAB//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQAC
AwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIz
NHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV
5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEi
EwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N1
4/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A9JxM
TFfi1OdUxznMBJIBJJ1JJKL9iw/9Cz/NCWF/Q6f6jfyI6SmtZjYFTC+yutjBy5wAGuiFPR/GjXza
jZv8009hbUT5APZJWYXerdda7BdvdPvNu3dO2mK527Paxj7H/ufpavzElN0u6MOTQPm1H+xYf+hZ
/mhUGvIwXsbV6PrVWufUXb3tf7WU1/8AXGf4Nq1klIPsWH/oWf5oS+xYf+hZ/mhHSSU134uCxjnv
qraxoJc4gAADlzig7ujeNGnOrUfOBOFeACSa3QBqeFnXXeplve7Cc/YHBt3qABwBDg2tjhtc+30K
tnqez/hP55JTaLujDk0D/NRxh4TgCKayDqCAFSwrRUB+hOP6hIsa57rCA1ntdv8Aos3We33/AM5/
XV7DaW4dDXAtcK2Ag6EENGiSlvsWH/oWf5oUbcPFbU8ilgIaSDtHgrKHf/M2f1T+RJT/AP/Q9Owv
6HT/AFG/kR0DC/odP9Rv5EdJSKy12/0ao9Ut3EkEtaOGudEfSd9Fih9kDtbbbXuPcPLB8mUljVXb
lOoDrfRsvddbY1zqwDtFZNVTXSW7Paz+op2dScx20YeTZoDuaxsat3/nPb/xbv8AhElJfTvol1b3
XMH+CfBdH/B2e3/wbfv/ANIxGrsZaxtlZ3McJafIqtZnvZuIxb7Ns/Qa2TE/RD3s/dTturostZts
IL94DWPcBuAc6NjT+f70lNpJV/ttX7lv/bVn/kEhmVExst1/4Kz/AMgkpJdaKmTBc5xhjBy537oU
DRZaZuscB2rrJaB/1xu217v7Wz/gln4/WftdjrW4eZUMc2MNF1Jre8h9dTb6G2fz1Oxz37mO/m1Z
d1G0VtezEudu3S2ACC1zWcfy/e9v9RJSb7M5nuote137thNjT8RY7e3/AK3Yz+2iVWl5c1w2PYYc
2Z0/NcP5LkEZr/Sreca4Oe0ucwNBLdv5rvd+d/g1Cu51l1GQan0G4OrdVZAdoPWrc/Y6xvs22M/6
6kpuod/8zZ/VP5ERDv8A5mz+qfyJKf/R9Owv6HT/AFG/kRiQBJ0AVCrqGPjYlPqyBLKQ4CZseG+n
WPztz9yHZ1bEueGy4VAB7mhp3O127XN+kyuuW+vu/wDPfqpKX6VnX3WZHrYr8Sh1724psIJeGhu+
3Yz2V132epZj/pLfV/nfZ/NrTWe7rPTntYHbi21osYHMOrPd+k2/ufonP9yEczFbv9O6+pjGl7xA
c0AEB3uvbZ++z9Hv/sJKdKyxlTC95gD5kk8NaPznOUcdlga59ullp3ubMhugaK2/1Wt/z1Rx8/p5
c9zHWXPrI9R7pcW62MLv3Kv5q31PSaj1dUxrW2PYHltOtpLSNsF7H/S+l6b6rGP2fuJKbiSSY6ap
KQ3jY9l4aXbJa+Odjvpe38/3srRmua9oc0hzXCWuGoIPcKk/rOExzWvLmlwa4EtMQ+Nvu+j+ez/t
xV7up9NYXPFttDmx6mwHQucWhr6nB9fqvsbZ/g/W/R2JKdZVqXNyMg5DDNdTTUwwRJcWvsd7h72e
yr03M/4RUzn4LLjXkW3WvbtGx4hs2b2Vt2VtZXY6yyqytjHep+mYh9Q6pZ9lsv6PWLs6tjXU1WzX
VY1zmsax1ga7979B+5Z9N9VD7klOyh3/AMzZ/VP5FWr6viWhxrDzs2gjaQZfs2iD9L+ep/7drUXd
UxLm2117i5rfd7TA3bdn/n2t/wDxb0lP/9L0XHx8F9FT7CN5a1x95HuDQzftDtrbPb9NT+ydNPJB
1B/nHcj6J+n+avmJJJT9OjE6YI27RAgRYRAH5rff9FN9i6X4N4j6Z4ndt+n9HcV8xpJKfpz7F0oG
QGAzMh5Go7/STjE6aG7AQGRGwWO2x+6Wb9u3+SvmJJJT9TevT/pG/eEvXo/0jfvC+WUklP04MLpQ
EQ3gN/nDw36Dfp/mfmJNwelMrFTQ0VgBoYHnbtA2tbt37drWr5jSSU/TlmD0qxr22BrxZpZueTu0
2e+X+/2HYn+x9Mjb7Y5j1DE/DevmJJJT9OfYulgEANAPIDzrru19/wC8dyazF6cKnbSNAXAeo6JB
9T6O/wB3v96+ZEklP//ZADhCSU0EBgAAAAAABwABAAAAAQEA/+IBoElDQ19QUk9GSUxFAAEBAAAB
kEFEQkUCEAAAbW50ckdSQVlYWVogB9EAAQAMABIAIQATYWNzcE1TRlQAAAAAbm9uZQAAAAAAAAAA
AAAAAAAAAAAAAPbWAAEAAAAA0y1BREJFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAFY3BydAAAAMAAAAAkZGVzYwAAAOQAAABxd3RwdAAAAVgAAAAUYmtwdAAA
AWwAAAAUa1RSQwAAAYAAAAAOdGV4dAAAAAAoYykgMjAwMSBBZG9iZSBTeXN0ZW1zIEluYy4AZGVz
YwAAAAAAAAAWR3JheXNjYWxlIC0gR2FtbWEgMi4yAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABY
WVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAY3VydgAAAAAAAAABAjMAAP/u
AA5BZG9iZQBkgAAAAAD/2wBDAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwM
DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAALCAD2AekBAREA/90ABAA+/8QAogAAAQUBAQEB
AQEAAAAAAAAAAwABAgQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIG
FJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieU
pIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/f/2gAIAQEAAD8A7eqrqXUOpdVA
6rk4lWJksoppoZiloacXDynEuysPJuc912Tb/hVY/Y3Uf/L3P/zMH/5GpfsbqP8A5e5/+Zg//I1L
9jdR/wDL3P8A8zB/+RqX7G6j/wCXuf8A5mD/API1L9jdR/8AL3P/AMzB/wDkal+xuo/+Xuf/AJmD
/wDI1L9jdR/8vc//ADMH/wCRqX7G6j/5e5/+Zg//ACNS/Y3Uf/L3P/zMH/5GpfsbqP8A5e5/+Zg/
/I1L9jdR/wDL3P8A8zB/+RqX7G6j/wCXuf8A5mD/API1L9jdR/8AL3P/AMzB/wDkal+xuo/+Xuf/
AJmD/wDI1L9jdR/8vc//ADMH/wCRqX7G6j/5e5/+Zg//ACNS/Y3Uf/L3P/zMH/5GpfsbqP8A5e5/
+Zg//I1L9jdR/wDL3P8A8zB/+RqX7G6j/wCXuf8A5mD/API1L9jdR/8AL3P/AMzB/wDkal+xuo/+
Xuf/AJmD/wDI1L9jdR/8vc//ADMH/wCRqX7G6j/5e5/+Zg//ACNS/Y3Uf/L3P/zMH/5GpfsbqP8A
5e5/+Zg//I1L9jdR/wDL3P8A8zB/+RqX7G6j/wCXuf8A5mD/API1L9jdR/8AL3P/AMzB/wDkal+x
uo/+Xuf/AJmD/wDI1L9jdR/8vc//ADMH/wCRqX7G6j/5e5/+Zg//ACNS/Y3Uf/L3P/zMH/5Gpfsb
qP8A5e5/+Zg//I1L9jdR/wDL3P8A8zB/+RqX7G6j/wCXuf8A5mD/API1L9jdR/8AL3P/AMzB/wDk
al+xuo/+Xuf/AJmD/wDI1L9jdR/8vc//ADMH/wCRqX7G6j/5e5/+Zg//ACNS/Y3Uf/L3P/zMH/5G
pfsbqP8A5e5/+Zg//I1L9jdR/wDL3P8A8zB/+RqX7G6j/wCXuf8A5mD/API1L9jdR/8AL3P/AMzB
/wDkal+xuo/+Xuf/AJmD/wDI1L9jdR/8vc//ADMH/wCRqX7G6j/5e5/+Zg//ACNS/Y3Uf/L3P/zM
H/5GpfsbqP8A5e5/+Zg//I1L9jdR/wDL3P8A8zB/+RqX7G6j/wCXuf8A5mD/API1L9jdR/8AL3P/
AMzB/wDkal+xuo/+Xuf/AJmD/wDI1L9jdR/8vc//ADMH/wCRqX7G6j/5e5/+Zg//ACNS/Y3Uf/L3
P/zMH/5GpfsbqP8A5e5/+Zg//I1L9jdR/wDL3P8A8zB/+Rqpdcw+rdP6L1DPp65mutxMa6+tr68I
tLq632sDw3p7XbNzf3l0a//Q7/o3/KPXf/D7P/bHpq1kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkklk/Wz/xK9Z/8IZX/nmxay//0e/6N/yj13/w+z/2x6atZJJJJJJJ
JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJZP1s/8SvWf/CGV/55sWsv/9Lv
+jf8o9d/8Ps/9semrWSSSSSSSSSSWZd9Z/q3Ra+m7q2FVbU4ssrfkVNc1zTtex7HWbmva5Q/52fV
X/y5wP8A2Kp/9KJf87Pqr/5c4H/sVT/6US/52fVX/wAucD/2Kp/9KJf87Pqr/wCXOB/7FU/+lEv+
dn1V/wDLnA/9iqf/AEol/wA7Pqr/AOXOB/7FU/8ApRL/AJ2fVX/y5wP/AGKp/wDSiX/Oz6q/+XOB
/wCxVP8A6UVvB6t0rqW/9nZmPmelHqfZ7WW7d07N/pOfs37H7VbSSSSSSSSSSSSSSSQcrLxcKh2T
mXV42PXG+61wYxskMbussLWN3PdtWf8A87Pqr/5c4H/sVT/6US/52fVX/wAucD/2Kp/9KJf87Pqr
/wCXOB/7FU/+lEv+dn1V/wDLnA/9iqf/AEol/wA7Pqr/AOXOB/7FU/8ApRL/AJ2fVX/y5wP/AGKp
/wDSiX/Oz6q/+XOB/wCxVP8A6US/52fVX/y5wP8A2Kp/9KJf87Pqr/5c4H/sVT/6UWnTdVfUy6l7
barWh9djCHNc1w3Mex7fa5jmqaSSSSSSSSSSyfrZ/wCJXrP/AIQyv/PNi1l//9Pv+jf8o9d/8Ps/
9semrWSSSSSSSSSSWT9Wv+Trv/D/AFH/ANvsxay5cZvWKuldQ69ZnOsb067PczAFdTan0Yl+TWKb
7PTdlfaHU0enVk03011fq/rYmV6WR9sLd1HqOPb1/qVmQ6zD6I57qcBja2CwNwcbNfXkZLq7rtnr
Xb6PR9F9T/U9b7VT6VFFjJ/afShVm39QszhbkY+PfivrprpH2q6rD34no1Nyqfs9t7LK25OVnfq7
H49v6az7bTDI6h1Gq23ogub+0spzzhZv6MNrquN9tT7cc/8Aajp9VNtePi7LP2p9l9f1fT/a1nSo
5HVM+rA6hg+rHWhkPx8E7W6/anPs6Vk11bd12JhYz/1y70LP+Suqf0n7LZv6BJZON/4quo/+EMH/
AM/dVWskkkkkkkkkkkkkkksn6y/8nU/+H+nf+32GtZZn1iyc3G6aLMGxtOS/JxKWWPZ6jQLsrHxr
N9W6vex1Vz/o2VP/ANHbU/8ASLM6vndT6Li51AzLMu09Mzc7Gyr2UiyqzEFLdm3Hpoxrqnuy6rK9
+PvqfTb6lmTXfWzGt2ftNuVj9Id1Cz1syu/LtzWV0h1baDi1fZMGh9VtVdT7czeyzN/aF9dDLafU
uttrysZMs6sLsvpNOV6+ViV4uXTlXtY11jLbb/Uwsn0KvRZ6n7Puo+2UYv6GjKr/AFWzIxfWyq9n
WOo9RxbOp9JLmYuE1jrMYCu2+8h+Lm5VdLKvX2v/AGc2/GwNl2zqVmf9qo/UvsHUMrQx+oOzertb
hXNt6fRjbr3s2uY+3INVuD6NzN/vpxKr7r697P0PUMC79N636LTSWT9U/wDxK9G/8IYv/nmtaySS
SSSSSSSSyfrZ/wCJXrP/AIQyv/PNi1l//9Tv+jf8o9d/8Ps/9semrWSSSSSSSSSSWT9Wv+Trv/D/
AFH/ANvsxaywcL6suYy6vLy7n42Rk5V9+A1zXY9jb8i7Jqbb6tX2pjPRspZk4lGRVhX7LfWpvZkZ
X2nTr6ZisOdvb6zOpWepk1WgOYf0NOC6vZt/mn04zN7LN/8AhFXp6IG2sORm5OZj0uD6MTINbq2O
YZoe6xlNeXlPx/8ABfbsnK/TbMqz1MyqnIrm/omK/Ay8Jz7P12yy6zIkes2x7vUpuqt2+23A20M6
fZ9PFrxMT/QKFXTbburnqebXSx2O11OIyol5c0k7MvJssrp25DKrLacamtv6mzK6j+tZP2/9DppL
Jxv/ABVdR/8ACGD/AOfuqrWSSSSSSSSSSSSSSSWT9Zf+Tqf/AA/07/2+w1rLP6701/VOnjDY7ZOR
jWvdvdWdlORRlXenbR+lrt9Kl/ovr2fpf8JX9NBf9Xqb8XLozsrIzbczHsxHZVvpCyum0bbasZuP
RRjVbnfpHv8As/qXPZT9o9avGxmU287p7MzZY22zFyqZ9HKo2+owOj1a/wBOy+myq7Y31Kb6bat7
Kr/6Rj491Vf9g478W2jJuuybMl1Zysmws9S5lTxYzEtbVVXj/Yns349uJVRVTbTkZX+Hysi6wuXi
WtyP2jhMbZmtpNHo2WGmqxpfXY05NtdOVbvxdt/2T9G/0/tOV/3J9RLo/S6ul4Qxq9pcXGy17Ghj
S535tdY3enj49QrxcOn1Lfs2FRjY3q2eirySyfqn/wCJXo3/AIQxf/PNa1kkkkkkkkkklk/Wz/xK
9Z/8IZX/AJ5sWsv/1e/6N/yj13/w+z/2x6atZJJJJJJJJJJZP1a/5Ou/8P8AUf8A2+zFO/rT25V2
Nh9PyeoHGcK8iyg47WsscxmR6J+25WG97/Qvot3VMfT+l/nPV9VlcB9YsW5ld2BRkdQx3Vsutuxm
Aiqu1rb6jbXc+nIstfjv9f7HiU5Od6Xpfq36zi+vP9vY7+oMwMSm7MdZTTk+vQGGgUZDraq8g5L7
a6tjfs+/069+RdW/1MSnJ9PI9GbOt4r+k4fVgyz7PnfZfSbA3j7Y+mjH9Ru7Z7H5NfrbX/8AbihT
17HttZ+huZhXODMbqLgz7Pa9x21Nqc212Q1l7/ZjZF+PTi5f6L7Lfd9qw/tM+ndYZ1G65lGNkNpo
supfk2Na2s20WuxbKq5s9a3ds9Vl1dP2bZ+j9f7VXbj1h+sGR1LFpxb8K+uqr7Xi1ZLHV73vZfk4
2M5tNvqNro/R22+pvx8j/gvQs/SrWWTjf+KrqP8A4Qwf/P3VVrJJJJJJJJJJJJJJJLJ+sv8AydT/
AOH+nf8At9hrQy8qjCxbszJd6ePjVutufBO1jAbLHbWBz3bWN/NVKjrT3ZVONmdPyennJca8ey84
7mvsax+R6I+xZWY9j/Qovt3WsZT+i/nPV9Jlip69j22s/Q3MwrnBmN1FwZ9nte47am1Oba7Iay9/
sxsi/Hpxcv8ARfZb7vtWH9pFifWbHyunVdTGJk04eQ7Fbj2WtY02HLsrxmbKvV9ZrKLr2etZZXWy
xn6bC+10+nYrHUet4vT8rHw7WWWZOXXa/FqrALrHUmhjqK9zmfpX/am2f6CqirIyMq7Hx6H2INv1
ixcfDsyMqjIotosprvwywWXt+02MxsaxtWK+9mRVY+z2vxLMj+bvoZ+uUXYy0MW6y+htttFmK90z
RaWF7YJb7jjWZFPu+n7Lljm/rGI3Ez8u5xvzbqabOjxUWV+s5rbGYt1LPtVuR06nflZV7r8jHyKc
XOs+zYlNlT8HeWT9U/8AxK9G/wDCGL/55rWskkkkkkkkkksn62f+JXrP/hDK/wDPNi1l/9bv+jf8
o9d/8Ps/9semrWSSSSSSSSSSWT9Wv+Trv/D/AFH/ANvsxVeqY+S/Ptud0vIuubtGF1LptlFVzKg1
rvs+VZmZeK6/Zm+vf9jspyel21/ZfWput9VVH9Hzacm7LzsXLzsjP9K6/wDZWbZi113MooxMir7P
bn9NY+pz8b1cbJ/S5FjLPQyK6fs1L8jT6R0y3B6g8ihtGK3p2Di0sZYbGtdjuzvVoZZZsvsZSzIo
/TXVV+t/24oY3Rr6+slzz/kzGsszcNmmmTlh9eV7t3rfq+7PyP0v6G39t+lWxn7NpWb076vHDbhd
Ntwc3J+xOoAzHZ9n2J32d1dlWT9idm2Wse30WW14P7M+z1Zn6r632T9eW70PFvxMKyrIbse7LzbQ
JB9l2Vk5NDvaXfTptrel1zFvy8KurHbve3LwrSJA9lOVjZN7vcW/QpqsetBZON/4quo/+EMH/wA/
dVWskkkkkkkkkkkkkkksn6y/8nU/+H+nf+32GtDL+1fZbvsXp/a/Td9n9afT9SD6Xren+k9L1P5z
Z79ixel4+TRn1DA6XkdJwTu+1UX2UHG2bXen9gxMLLzG4mX9p2Pf6NWNi302ZlmV62X9kVLp31eO
G3C6bbg5uT9idQBmOz7PsTvs7q7Ksn7E7NstY9vostrwf2Z9nqzP1X1vsn68tfpPS/8AsVw+j9Sq
/wC0FWJmU7v+BbRkVepS7+uzfVYsqz6u9SyaWZ3UXWZPUcfIYXNps+y2XUY1WVgVNpyMO2lmPblv
zczrFbd9XvzP2TlX141f2imbej22Y9lmP0/JxrbMnpxcc7LOTe6vFy68y36eVn01Y+PS66yrZl+t
dZ6/6t/M/aOoXP8ATMnqjspuV1Ho+W3Mvis2b8R1ONU4tLqKNmc651TdrLMvI9D7TnWV+p6PpVYW
FidAsn6p/wDiV6N/4Qxf/PNa1kkkkkkkkkklk/Wz/wASvWf/AAhlf+ebFrL/1+/6N/yj13/w+z/2
x6atZJJJJJJJJJJZl31Y+rd9r7ruk4Vttri+yx+PU5znOO573vdXuc9zlD/mn9Vf/KbA/wDYWn/0
ml/zT+qv/lNgf+wtP/pNL/mn9Vf/ACmwP/YWn/0ml/zT+qv/AJTYH/sLT/6TS/5p/VX/AMpsD/2F
p/8ASaX/ADT+qv8A5TYH/sLT/wCk0v8Amn9Vf/KbA/8AYWn/ANJpf80/qr/5TYH/ALC0/wDpNW8H
pPSum7/2dh4+H6sep9nqZVu2zs3+k1m/ZvftVtJJJJJJJJJJJJJJJBysTFzaHY2ZTXk49kb6bWh7
HQQ9u6uwOY7a9u5Z/wDzT+qv/lNgf+wtP/pNL/mn9Vf/ACmwP/YWn/0ml/zT+qv/AJTYH/sLT/6T
S/5p/VX/AMpsD/2Fp/8ASaX/ADT+qv8A5TYH/sLT/wCk0v8Amn9Vf/KbA/8AYWn/ANJpf80/qr/5
TYH/ALC0/wDpNL/mn9Vf/KbA/wDYWn/0ml/zT+qv/lNgf+wtP/pNadNNVFTKaWNqqqaGV1sAa1rW
jaxjGN9rWNappJJJJJJJJJLJ+tn/AIles/8AhDK/882LWX//0O/6N/yj13/w+z/2x6atZJJJJJJJ
JJJJBysvFwqHZOZdXjY9cb7rXBjGyQxu6ywtY3c921Z/7f8AV/oPTc/Mj+c/QfZds/R/5Zf0z1t/
u/o3r+n/AIb0/wBF6i+2/WS330dLx66j9FmXmGu4RofVrwsTqOM33fQ9PNu/R/6Oz9Exen9aqv0n
2jAzI/7T+hdi7p0/pn2rqfo7Pp/0G/1P5r9H/PVr9o9do/pXSPW3fQ+wZNdsR9L1/wBpN6Ns/wCC
9H7T/hPU9H9H6q/5zdJr0zn2dMI0cc6t+PWH/nUMzb2twMi36X9Eysj1WMsuo9Wn9ItZJJJJJJJJ
JJJJJJJJJJJJJUc3rPTsG0UXWOfkubvGNRXZkX7CS31zi4bL8huPvb6f2j0vR9T9H6m9V/2v1O/2
4fSMj361X5dlOPSW/S32hlmV1Kjez6FdnTPX9T9HkVY/6T0l/wBlV/8A3A6dt/47O3z/AO4T7P6f
/oT6u/8AwPpfpVu+tVHs9PAz519X1LsKP+D+z+l1nf8Avet9qr/c9D9H6lq/bmTX78ro+fj0j6du
2i/b+7+r9Nys3Ns3O9v6HFt/fs/RepYreD1TA6hvGLbutpj1qHtdVdXun0/tGJe2rJx/Va3fV61T
PVr/AElf6NW0kkkkkkkkkkklk/Wz/wASvWf/AAhlf+ebFrL/0e/6N/yj13/w+z/2x6atZJJJJJJJ
JJJZP7Xvz/b0KuvJpOh6m94+yA8P9D0S67qFtO5v6Or0MOz9NjftPHyqbKkbF6Ji03tzMh9mfnMn
Zl5RD3skGt32auttWLhb6v0V32HHxvtP/an1rPetBJJJJZP7E+w/pehv+x7df2fMYdkf4P0Ntn7P
3TZ+m6a2j9Ys+1ZlHUP5hGxersfe3Cz6/sGe+fSx7HtcLg0F1luBa0/rVTNj/wAynMpq9O3Lw8X1
6d+gkkkkkkkkkkkkkkkkkq+b1DCwKhbmXNpa92ysHVz3kFzKMeps25GRZt/RY9LLLrf8HWqP2TqX
U/d1B9nT8X83Cxbttjwfc1+bm0NruotZ7P1bpuT6TH12+pndRx7/AE6r2F07p/T6jTgY1OJU5291
dFba2lxAaXllTWt37WtVhJJJVM7peB1DYcqrdbTPo3sc6q6vdHqfZ8uh1WTj+q1uy30bWerX+js/
Rqp63Vume29lnVcManKZs+1sB9z/AF8KmvHpyaqof+kwP1x/6HGr6ZkW+plW6GLl4ubQ3Jw7q8nH
snZdU4PY6CWO22VlzHbXt2oySSSSSSSSSSyfrZ/4les/+EMr/wA82LWX/9Lv+jf8o9d/8Ps/9sem
rWSSSSSSSSSWT/y5/wCmb/28/wDlV/8AFX/01f8AKuskkkkkkkg5WLRmUOx8hu+p8SJLSC0h9dld
jC2yq2qxrbKbq3erTb+lq/SKr03Kva93TuoOnOq3ursIAF9AdtpymbAyt9rK3019QZXXT6GZ/wBp
6sTJwfX0EkkkkkkkkkkkkkklXzc2rCqD3h1lljvToorg2W2EFzaaWuLW79rXvc572U00ssyMiynH
pttZX6Z0z0NudnNrt6xbWG5WU0TE7XvxMR72tsq6fVY39BR/6EZHq5luRkW6CSSSSSSSzM/p7qbX
dU6ZS0dQ3MOS1u1v2qppay2i/dsZdkV47Xfs626yr7PkenX9oqwrsyu67i5VGZQ3Ix3b6nzBgtIL
SWWV2VvDbKrarGurupsb6tNv6K39IjJJJJJJJJJLJ+tn/iV6z/4Qyv8AzzYtZf/T7/o3/KPXf/D7
P/bHpq1kkkkkkkklk9X/AF++voTdacmt7+pkcjEg0+hvG70beoXO9Kv2/pMOjqf2a6nKx6rFrJJJ
JJJJJJKvm4VWbUGPLq7K3epRfXAsqsALW3UucHN37XPY5r2PpupfZj5Fd2PdbU8PR823MwgckNZm
0ONGbWyQ1t9ftsNbHl1rce/25WH6v6S3Cvxr/wDCq8kkkkkkkkkkkkkoXXVUVPuue2qqppfZY8hr
WtaNz3ve72tY1qz+j025DR1bNY5uXktPo1WAtdj473epRi+i7+YyHVNos6n9P1M32es/GxcKujTS
SSSSSSSSWT1L/Jl7erU+zHfYxvVW/mmsj0K8/boyu3Cf6H2rKc+tn7JryPtHr/ZMH0NZJJJJJJJJ
JZP1s/8AEr1n/wAIZX/nmxay/9Tv+jf8o9d/8Ps/9semrWSSSSSSSQcvKowsW7MyXenj41brbnwT
tYwGyx21gc921jfzVV6Ji304r8jMbszs+w5WWyQdj3htdeNurPpP+xYtWPg+tV/Sfs32n+cuetBJ
JJJJJJJJJZPUP1DquN1QaU5WzAzfLe8/su/8536LNyLMP0qme/8Aan2jIs9LCWskkkkkkkkkkkkk
snrX61fg9HGrMyx1uYzucTHAsuHu/RvqvzLOn4OVQ71PXw8zI/R/zl1OskkkkkkkkkkoXU1X1Ppu
Y22q1pZZW8BzXNcNr2PY72uY5qz+gXWnCfh5D3WZPTbn4ljnkue5rIfhXX2/4XIyenW4eVkWM/w1
9n8y/wDQ16aSSSSSSSSyfrZ/4les/wDhDK/882LWX//V7/o3/KPXf/D7P/bHpq1kkkkkkklk9f8A
0v7NwePtmfR+k52/Zd/Wfo/n+t+zPs30v0fr+t/g/Ss1kkkkkkkkkkklR65hW9Q6L1DApLW25eNd
RW58hodZW+pheWhztm537qN07Nq6h0/Gz6Q5tWXTXfW18BwbY1trA8NLm79rv3lYSSSSSSSSSSSS
WT0n9a6l1Pqf5jrG4OO4aB1eH6gte5rvf6rOp5PU8Z35j6sej0q/8PfrJJJJJJJJJJJLJu/VPrJR
edKuqY5xHuOv6bGNmbhVVhvub6uNf1ay57/0f6rR/NWf0jWSSSSSSSSWT9bP/Er1n/whlf8Anmxa
y//W7/o3/KPXf/D7P/bHpq1kkkkkkklk5v6X6ydLofrVXj5mWxvEXVnEwq7ZHu9uN1HNr2fzf6b/
AEldWzTuuqoqfdc9tVVTS+yx5DWta0bnve93taxrVlXfWLEfj3txnuxcoU2Ox39Sx8nExy9jH2j1
LsunGa5jGsdddXU/1vs1V93+CsVjM690zCyjhXPsdlitt32eim6+z03mytt3pYlV1npepS9lln0K
X+l6v9Io9S7TdVfUy6l7barWh9djCHNc1w3Mex7fa5jmrPu+sXSqbX1vfdtqcW25Dce92OwtO271
c+ul2DWzHcHsybH5GzF9O37R6fpWKeV13p+Le7HeMi22uPUGNjZGSGEgPFdtmFRkV1W+m5lno2O9
X0rKrf5u2tLI690yj04fZk+tW25n2Sm7L/Rv/mbnfYKsn06r9r/Qss9l/p2+j/NWK1i5VGZQ3Ix3
b6nzBgtILSWWV2VvDbKrarGurupsb6tNv6K39IquV17pmJe6i99k1R69jKbrKapAf+t5dNVmLiba
nMvs+03VeljvZkW/oX+ollde6ZiXuovfZNUevYym6ymqQH/reXTVZi4m2pzL7PtN1XpY72ZFv6F/
qJZnXumYWUcK59jssVtu+z0U3X2em82Vtu9LEqus9L1KXsss+hS/0vV/pFHqLF6/0nMvbRi3+r6k
+jc1jzRaQC99eLnbPsWVaxrLN9OPkW2s9HI/7j3+noLJ+q/s6LTjD6GDZfg1Hua8O+7p+O+z/hX0
41brtvs9X/B1/QWskkkkkkkkkkqmR1bpWLlV4WTmY9GXft9HHstYyx+8+nX6dT3Cx++wbGbfz1bW
T9VPd9W+nXnW3Lx2Zd7v3rskfbcu2Pot9XJvts2M/Rs/wf6NGyuu9Pxb3Y7xkW21x6gxsbIyQwkB
4rtswqMiuq303Ms9Gx3q+lZVb/N21qH7bwqMfKz8vMxv2fXdU2nIqfua1l7MX0ftbxuYx9l+V6jb
P5n7FdjX/v2Kxg9Uw8/eMc2NfVG+q+qyiwB0+nZ9ny66LvSs2WNru9P0rH1W/wCisVfrXWG9Kf09
1ha2jLyTj3EhznR9nysipmOyv32ZFuRj001VNZa+71PRqq9aytC6h9YsWnpR6ljva2urJxqMn7S1
9Jqbbfj0XnIpyPs92M9mLk/aK/Xaz2ejke+hLN+sNI6L1PPwd32np+NbkCjJptodLa7LaX2Y2SzG
yPs9r6ns9Vvss9O6uu3fVYrWF1np2faasaxznbd7C6uyttrAQ034dtzK6s3H99f6xiPvp/TUfpP0
9O+3ddVRU+657aqqml9ljyGta1o3Pe97va1jWqphdYwc6000+tXaG7xXkUXYznNBDXvqZm1Y7rmV
ufX6vo7/AEfVp9X+eqUcXr3TMu9tFD7Jtn0LH03V02wC/wDVMu6qvFy91TX31/ZrrfVx2PyKv0LP
UVen63fV+6pl9eS40XNDqLvRuFdrnCW4+Lc6r0srN/M+wY7rc31q7qfs/rU2sWhhZ+Ln1G3Gc4hj
tljLGPqsY4AO2XY+Q2q+l+x7LW+rX/M2V3fzVjFR+sP6KvAzW624mfjemD9E/aX/ALIu3/ne3G6j
e+v/AIf0v8H+ifrJJJJJJJJLJ+tn/iV6z/4Qyv8AzzYtZf/X7/o3/KPXf/D7P/bHpq1kkkkkkklk
1/ovrVkepp9swKPs/fd9luyvtnH0PR/aeD9P+c9f9F/N3ene6iHO6fktZjNzXGmwNw3lrW3Ha6MZ
7rQ6prL/AOa/Sexcl1XdkdLzcLptWfn1PxMvZTnY2QH47zjZFdd+Dm9Rx68rJtyLbfsb8Sy/Myv1
39V+zYeLfRbq3dRrwPrVmuupyLKn4GEPUx6X5G1wu6ntY+nEbdk/pG79tnoeh+i/S212Po9a10ht
/T8OijIos9XNy8q0tYA8UjIsy+qV/a3sca2bKy3GsfW+6r7Y9lVVltf6VYXXKX9Rwup4mYzqJ6te
3Jx8KigZrMTa71aumNdbibelWMyKjRfl2511uy2+6nKfRj0/Zca7mZNGRmWu6oOpsx/Y7pzMKvPr
BpfXVZZdk/spjbW5bsp19D8bOd6mPVjU7MWj1rbsqrhi2jpvTMDq9efRiYmBj1NZhMy95y6t+Nnt
yLektdk+ljNpo+ye+vCzPtNuRV9u9Oi3F0vqu442I3p5x8lu67NvZbcyyBW/J+1Ywvvyv0zsjIxe
oU2/pN92+rMqyfTy8XIqSwsw9HZdgZGNk3ZD8nKvo+z0WW12Nyci7MoDctjPsmO/9Y+z2/br8T0b
q32Wfqfo5Vqwsw9HZdgZGNk3ZD8nKvo+z0WW12Nyci7MoDctjPsmO/8AWPs9v26/E9G6t9ln6n6O
VbH6udMyum5Qxshs/Z+kdNxTc0H03WUHqDL21WOazfs31u/f2W1oPTsTKZ0r6n1vpsa/F9L7S0tI
NUdOzKHeu2P0W257Kf0n+F/RrplznT+n5edldT6hj9SycGjKzbGsppbjHXFZV0m6yz7XiZb978jp
93p7Ltn2f0P5u71Vd/Y3Uf8Ay9z/APMwf/kal+xuo/8Al7n/AOZg/wDyNS/Y3Uf/AC9z/wDMwf8A
5GpfsbqP/l7n/wCZg/8AyNS/Y3Uf/L3P/wAzB/8Akal+xuo/+Xuf/mYP/wAjUv2N1H/y9z/8zB/+
RqX7G6j/AOXuf/mYP/yNS/Y3Uf8Ay9z/APMwf/kal+xuo/8Al7n/AOZg/wDyNS/Y3Uf/AC9z/wDM
wf8A5GrzX/GN9UfrL1L6z4tWCzL6vuxGj7VaypjGlr8h7qHZOPThYVe1vv8A036X9L/xS3fqV9Q/
rb0mqp+Z127Cq2uB6bj7b2sa8C32uzBfhUZDcn+d9HDv/P8ATyf06636p/8AiV6N/wCEMX/zzWqX
UbWY/Uci1rc3p+Xuaa78XHyMzHyWCuuLM3FxaL8Vr/Wb9kt9+N1b7Nh1elm0Y11Sz7a8rG6RnW2d
PdiOd1XpNlWBXsgbR0Ov7Ni2H0MWxlV1VmIy3fXj76v8GtvGsPUutUdRoqurxcTGyMdzsiqzHc6z
Isw7WtqoymU3uZSzC/S2uq9H9NT6D7v1n7OHquVbYzoPU2YeS6tuT9ovoFRN9NdmFmsc7IoadzX0
OvY22pnqXep+gx2X5HpU2Uupsysw5XV8XEyLarLOk10Y5rNV9n2POdl5NjcbK9B9NWzK2Nfl/Zv5
i+5+zD9HJuXXm3dZxc/LwcfINVPSOoYjW20W02W3ZIx31VY2LkV1ZNmxuH73+l6e++mvH9ez7T9n
0HXv6t1Dpxpx8ij9nZD8jL+01OqDScfKwm49Vjx6WZb6uXu9TCsycP0qLf1r9JifaS9Xbf1DDvox
6LPVwsvFtDXgMFwx7MTqln2R73Ct++sOxq32Ppq+2MfVbZVX+lQs7JHX+ldR6Zg1ZFb8nEuqF+Vj
3Y1bX2sNNLXfbKqbrN+9z/1am/0mVfpvT34/rQzcw9YZTgY+Nk05DMnFvv8AtFFlVdbcbIpzLw7L
ez7JkP8A1f7PV9hvy/WusZZX+p+tlVV+nYmUzpX1PrfTY1+L6X2lpaQao6dmUO9dsfottz2U/pP8
L+jWn0mm2vP60+xjmNuzWPqc4EBzRh4FW+sn6bPVrsr/AK9ah9Zf+Tqf/D/Tv/b7DWskkkkkkkks
n62f+JXrP/hDK/8APNi1l//Q7/o3/KPXf/D7P/bHpq1kkkkkkklk9R/Qdd6RlfS9b7TgbOI9WtvU
vX3fyP2N6Ppf92fU9T9D6duskoCmoWuuDGi17WsfYANxawvdWxz/AKTmVutt2f8AGWKaSSSSSSSS
Syfqr7/q/hZJ+nnV/brR2FmY53UMhlf/AATLsmxtO73+l/hLPprWSSSSSSSSSSSSWT9VvZ0LFxef
sHqYG/8Af+xWWdN9fb+Z6/2X1vS/wXqen6ln84tZQtpquaGWsbY0Oa8NcA4bmOFtT4d+fXaxllf7
j1NJJJJJJJJJZPXv0tnSsJ2lWXn1+oR9IfZmX9Xp2fm+7J6dQyz/AID1f8J+lZrJJJJJJJJLJ+tn
/iV6z/4Qyv8AzzYtZf/R7/o3/KPXf/D7P/bHpq1kkkkkkklk/Wb9H0l+cND0yyvOLh9MV47235rK
Hf6XIwG5WJ9JjLftHoXWejbYtZJJJJJJJJJJJZn1kutr6JlMoe6rJyWtxMa1pLSy/Kc3Bxbt7ffW
yrIyKrLLK/0lbP5ve9aFNNVFTKaWNqqqaGV1sAa1rWjaxjGN9rWNappJJJJJJJJJJJLJp/VPrJfQ
NKuqY4y2NGv6bGNeFm22F3ub6uNf0muljP0f6rf/ADVn9I1kkkkkkkkkkklk4v639YM3JOrOm1sw
aQdC2y1tfUM97dv06r6bOkNb6nvZbi37K6vp5Gskkkkkkkksn62f+JXrP/hDK/8APNi1l//S7/o3
/KPXf/D7P/bHpq1kkkkkkkkHKy8XCodk5l1eNj1xvutcGMbJDG7rLC1jdz3bVhfU3rPTszCOFg2O
sxcVzm9NtfXZULsRmwV/Z/tDK3XM6a639l32b7rd+NXkZP8ATK10aSSSSSSSSSSyW/5S6yy1vuwe
lb/TePovzHizFu2O9rv8nY3r49n87j239Qtq9mX0xaySSSSSSSSSSSSSzOvU2/Z6c+hjrr+l3DLZ
SwFzrGhluNl011t91uQ/Bycr7HXur/Xfs3qfofUWhTdVfUy6l7barWh9djCHNc1w3Mex7fa5jmqa
SSSSSSSSSr9QzasDCuzLQ57aWyK2QXvcfbVj0McW+pkZFpZTj1f4W6yutB6NhW4PTq6by12S91l+
SWSWevkWPzMoUbg1/wBnbkX2/Z/U/Sej6fqe9Xkkkkkkkklk/Wz/AMSvWf8Awhlf+ebFrL//0+/6
N/yj13/w+z/2x6atZJJJJJJQuFpqeKXNZaWkVve0vaHR7HPra+p1jGu/M9Wv/jF4P9frvrdldcfg
dSyLM/HdkOr6eMZjm41j2uLfTxKGyy3Lxn5H2O/35OVTd+qWZFq9bx/q5+xeh4FHSh6uZ0atzqWz
sGS57XHMxbXWPd6NXULnev8Az3oYuYzDyNl1WH6C2sXKozKG5GO7fU+YMFpBaSyyuyt4bZVbVY11
d1NjfVpt/RW/pEZJJJJJJJJUc3NtbaMHBDbM6xu/3ya6ayS37VlbS12zc17cbGa9l2bcz06/Ropz
MzEN0/CqwMKnDqLntpbBsfBe9x91uRe9ob6mRkWl92Rb/hbrLLFYSSSSSSSSSSSSSSWTi/5Ge3Bt
/wCTrbCMK/tU6xxdX024fQqqa9/odKsZso9L0emfosmvE/aOskkkkkkkkoXXVUVPuue2qqppfZY8
hrWtaNz3ve72tY1qzG/5avoyG/8AJeLYLqHcjKsaHCq7afZ+z8d7vtGLZ9PLzKsfNxvSxcbHv6hr
JJJJJJJJJLJ+tn/iV6z/AOEMr/zzYtZf/9Tv+jf8o9d/8Ps/9semrWSSSSSSWfnZV9mUzpeE708i
2s235IAd6FIIrDgxwez7XkvL2YP2hv2f9Bl5H6x9i+x5JW9K6a2ijHONXZVi2C6gWj1C24Fz/tXq
Xb7PtfqPssflOd9ofbZZb6nqPVtZ+V017b3dQ6c70s4wbK3PcKLwAGbMqlu+tlr62V1s6hXT9so9
HH/pOJV9hvsYWbVm1F7A6uyt3p30WQLKrAA51NzWlzd+1zHtcx76bqX15GPZdj3VWvsJJJJJJKjm
5trbRg4IbZnWN3++TXTWSW/asraWu2bmvbjYzXsuzbmenX6NFOZmYhsLCqwqixhdZZY71L77INlt
hAa665zQ1u/a1jGtYxlNNLK8fHrpx6aqmWEkkkkkkkkkkkkkklC6mq+p9NzG21WtLLK3gOa5rhte
x7He1zHNWZ9pv6P+jyxZf0xurM8uDnY7P3OpGx/rW1Ve30+oMbd+g/SdV9L7Ld1LL1kkkkkklC66
qip91z21VVNL7LHkNa1rRue973e1rGtWZtv617ciizF6X+dRcA2zKB1b61Qc5+P0/Z/OYuR6WZlv
/Vs3HxsWq/H6gqP8j5QxXezpN+xmEeW0XOLmOwXO/wADiXfoP2Yz+brv9bA9Wn/JWEtZJJJJJJJJ
JZP1s/8AEr1n/wAIZX/nmxay/9Xv+jf8o9d/8Ps/9semrWSSSSSVHqmbbj1ehhhtnUslrhh0ukt3
Af0jJ2lrmYWM59bsq3+pRT6mXkYtFxsLCqwqixhdZZY71L77INlthAa665zQ1u/a1jGtYxlNNLK8
fHrpx6aqmWEklRzej4WZaMkh1GaxuyvNoPp3taCXsrNjf5/Hba71fseU2/Cts/n8a1V/2h1XA06p
jfaqR/2twGPfH/H9LnIzavc5lVX2Ozqm/wDSZGR9iqVjC650XqFppwOoY2Xa1u91dF1djg0ENLyy
p7nbNzmq8kksy76ydErtfQzKbk5NTi23GxGuyr2Fp2v9bFwW5GRUyt/6OyyyrZXZ+j+m9Q29Z6l7
bWfsrBdo+veH5j2/nM9bFs+zdO9zf5zHv6hfbj2/oremZbFewun4WBUasOltLXu32Eaue8gNffkW
um3IyLNv6XIufZdb/hLFYSSSSSSSSSSSSSSSSSSWT+yL8D3dCsrxqRqemPYPshPL/Q9ENu6fbdtb
+kq9fDr/AE2T+zMjKustS/5w4uL7OtN/ZNo035DgMZ5/7rdQ0xn73Cz0ce/7N1H0a/XtwKa1p03V
X1Mupe22q1ofXYwhzXNcNzHse32uY5qmkq+b1Hp/T6hdn5NOJU52xtl9ja2lxBcGB9rmt37WuVH9
u/bPb0Oj9pf92t/pYY/9D9l32n6Nlf8Ak2jP9HIZ6OZ9lU6eitttZl9We3qGXW4Pq9rmY9TmGabM
XAstyKqsiv6X2yx92b+ku2ZNeN6eNVpqF1NV9T6bmNtqtaWWVvAc1zXDa9j2O9rmOas/Cutwso9M
zHudW93+TL7CXGysMD34t17vdZm4zm3ub6v6bJwPTv8AWzMijqV1Wmkkkkkkkksn62f+JXrP/hDK
/wDPNi1l/9bv+jf8o9d/8Ps/9semrWSSSSVfNzasKoPeHWWWO9OiiuDZbYQXNppa4tbv2te9znvZ
TTSyzIyLKcem21gem4VtDr8vLLXZuY5rrtkuZW1jdlOHj2PDbXY9Hvs92z1cq/Ly/QxvtX2eu8kk
kkkq+b07p/UKhTn41OXU129td9bbGhwBaHhlrXN37XOVH/mv0VmmNTZgs71YN9+HWT/pH4/T7sal
9v5vrOr9XZ6f+jYl+wbHfo7eq59mJwMb1GM9o/m2fbseinq36P2/pP2h693/AGqtv32+ov8Amr9X
365OFXnP7W527MsA/wBGzI6g7JuZV+d6LbPS3+p/pHrTppqoqZTSxtVVTQyutgDWta0bWMYxvtax
rVNJJJJJJJJJJJJJJJJJJJJJJZl31Z+r11r739Nxhk2OL3ZLKmMv3uO43syqmsyK8jf+k+0V2+sy
z9J6m9Q/5vV1e7Cz8/EtOhs+0vyZb+56PV/2jjN93+EZR6//AAvp+rvX/N3Gs9+VmZ+Rcfp2/bL6
N37v6v02zCwq9rfb+hxav37P0vqWKxhdD6L0+03YHT8bEtc3Y6yimutxaSHFhfUxrtm5rVeSSSQc
rFozKHY+Q3fU+JElpBaQ+uyuxhbZVbVY1tlN1bvVpt/S1fpFz/U/rfi/VjAd/wA4XWPya7Cyj0mA
vyqy53o30/zOP6tePt/aX9GZRlfQpZj5XTvtPR03VX1Mupe22q1ofXYwhzXNcNzHse32uY5qmkkk
kkksn62f+JXrP/hDK/8APNi1l//X7/o3/KPXf/D7P/bHpq1kkklC66qip91z21VVNL7LHkNa1rRu
e973e1rGtWf0+m3OdT1bOY6txbvwsN4LTjte2N97Hf8AenZU/Zkf9w2epg43/azK6hppJJJJJJJJ
JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJLzf6+/4suqdbzbesdPz3ZOSWx9jyiGgNb6j204V1bW
VVs/m66qLq/p+rkZGbvetP8AxZ9Q6lVgW/VnrdVmN1PpX8yy7R1mKXOrrspc97/tFWPcyzH9ahv2
RlH2Oupdqkkkkkksn62f+JXrP/hDK/8APNi1l//Q7/o3/KPXf/D7P/bHpqz+ifV7oGbi5GTmdMxM
nIsz+ob7raK3vdGblsbussY57trG7VHrn1f6Dh1VOx+mdKxw9xaXWdP+12OdG5lGN0/CFF973M9a
+2xlv6CnH/o9lXq342VRjdLyWU4+N0TpTsp3UT0+y+/pxxmlv2J/VftI6fkN+10vp9jPs9t3656X
9IxftTLca1j/AFcqzMvOxqum9Dob0+6ug3O6cLTa52Ni5dp+ztyMf7MxluS/0/1nJ9Rj/S/R/Z/W
y1idM6L1irFHTejdKw7bcLG6he/Iw68hrW5Ys9DGqrpOE6x+7Hv9XIfbV6eyn9Xu+0fqkXdG6Bbn
dOxbekYDMjG6m/EzTVjVtqt/yflZ9bmsLXP9J7LcW70LfU+z5LPT9XI9CvKtr5nRen5XTcHqtPSu
lVdPz8np7q6G4jWZDKL8rF2Otym76b330v8ATycP7NRXX9ptr+2ZX2f9dln9K6Bb123Dx+m9MxKs
Ct73XZGNX6LXVV49+dkZVdXoOyqq8bqvT6sSp+Ti0V2WdRzMn1LMLp3qG6F0HpXUM2vIyuh4GMW4
m7PxRjsLK7L7PtHTMX9LUPT6hhYHq/tX9HjP/XML2W0/Zvs1freL0fpbsy/9l9Ksrwmvtdh09Ity
DtY31mUZHV8eMPCyMij07nfaMT9RZkV7/tVH6xkFz+mdPpZ17Kp6N0duL0Rthra/Da+y1zcKnPY1
+00soZVff9P9N9pp/Q+niej9ovtj6vdPxM7CZn9J6PZV1G51DaaMFrXUuFORnAnLtdY3MYxuI7H/
AKFher6n2j9D/R1X/ZfSv2V/zk/ZHSP2T9n+2/YvsLPtP2bZ6+77b6n2f7X9n/T/AGf7F6PrfqP2
v/vRSb0boFWd1HFq6RgPyMnqbMTCNuNW6qr/ACfi59jnMDWv9JjKsq70KvT+0ZL/AE/Vx/Xsyqi9
K+q/Sv2/1DG6j0vplvpYmG6s0YrGVnfZ1Hfb9ltF/wBmtd6bKbP1jI9VmPVb6n/aeix1z6v9Bw6q
nY/TOlY4e4tLrOn/AGuxzo3Moxun4Qovve5nrX22Mt/QU4/9Hsq9W/Gz8bC6JkdMy7f2V0qm3CyR
jWZV/THVBwdVRk1uq6Na1ue/Itsy6cGjE+1b8h/61R6nqU4VgsfF6PY3Mod0vpTLMRuPacy/pFuM
A3IdkUsoq6RkfrmdkOvxGU0ejl1faH5n6H9Pi/Z8u70Dpn1fzsrLwsno+BY/FrpuF37LdgyLzkV+
l9j6g2279H9j3/aW2+lb63pen+rv9Sxl/V7ot3UH9N6b0npVFtFNeRffkYNdzdtzrqaKqqKXYjnP
c7Evfba+/wDQ/of0OR9o/VYXfV/pTX4vTG9H6QzqeRXda7IOGx9Da8d1NT7W436G51uR9qxtuL9p
2Y3qX/ruT9lr+20snpnT8fOx+jDo3R7OoW3VtfknDayg0XU9RvrubjzbczIx7ulW78b7RZXk1+n+
t4v2v9Qhf0vFx8bqmQ/pHRXM6DuOSRggHK20VdSdXRX6h/Zm2m9mP61lvVPVt/T+hT6fo29L/wA0
/qr/AOU2B/7C0/8ApNVaek9K6b9asL9nYePh+rgZvqfZ6mVbtt3TNm/0ms37N79q6BJJJJJJJJcz
0T6vdAzcXIyczpmJk5Fmf1DfdbRW97ozctjd1ljHPdtY3asjrvRen5HQer9Q6d0rpVGLjU5tLWOx
GtyC7G9fFvy6syr2Yr6r6bbMan7Lket6NX61i/av1LQo6B0/J6l1KqnovRxi9Ou9Gtj8Vosuc7Fx
8tjH3NY5mGyu/J/n/s+b61P6P7NT6Hq5NHBxOhO6nh4tvTemZ1OdY+pltPR7MWv203ZjcmnPynZe
Fm1WNxdlbMd/6Zl32qq70qf0k3dM6e7Bw+s09G6Oen9Quw214z8Novroy7qKGXPyGl1N+R6N/wDR
vs9FePZb/S8v7J+u3bPq70rNzMrH6Z0vpGKzAsbRe/JwGXl9jq6sv9FXTbhelVVTk0/pH2Wvut9X
9FR9n9TKpYnTOn9WzrsXA6N0fDbjUsdfZfhtyCL25HUOnZNNTKjg+tjut6b6lGS99Fmz+cxP1n9T
r5+J0CzCxMb9iYDcjJyL8bIdVj10h7cfKZ0P9Bd6d12F9s6jl4LrNn2i/D6dZm/Zr/t1GLZZNvRe
n5Oa3Cd0rpTrKs2qrGycbEbW21tH6frl9+O77Sz7FVj2/sZn6TL9Lrf879lv+z/ZNfqP1f6A3Kx+
m4PR+mV5eTXbeL78OuytldBoZb+hr9Cy619mXRXXX61DNnq3+r+h+zZOLT0bFqy78T9kdIsy8jq4
w9z8YGmusdMrzvXoq2+pX+kp+1fYfU2epbdi/bPf+0Vb6l0bpmJe2j7D0hrxWwuZT0W7Oe6RDsm2
vAe39n1XXNvrxqLvtG/7PZ+uXfpqseWJ0zovWKsUdN6N0rDttwsbqF78jDryGtbliz0Maquk4TrH
7se/1ch9tXp7Kf1e77R+qRw+m9KzqaMVvQ+kY/U8izO3POIy6iqvByfsD9rNuLdlW2epjMb78Nn8
/lfo/SrwrlmdN6Vg034ruh9IyOp49mDteMRlNFtedk/YGbmbcq7Ftr9PJY735jP5jK/SerZhU2sX
6u9Ko6rV07qPS+kZP2nHuyK7MfAZj7Ps78ap7HsttzvW9b7cza7fT6Xo/wCF9X9ELqv1X6V+3+n4
3Tul9Mq9XEzHWG/FY+sbLOnbLfstQo+02t9R9Nf6xj+kzItt9T/tPfX6n0forulXsr6N04dSweo4
OJaWUV1VWuffgXe14quupx8rFzK2ZFey/wBD1L8f9crr9bIh1zofSsLpXU8PM6Z0x+W/pmZl4mXi
YbMfb9nYyuxrq7H5VldtdmVj20X1ZH6T9L+ix/s7H5WhX9X+lYuZi1dT6P0ixnUbHVUNxsNjTTY2
u3M9K227f9tq9HGuZ9qZTgv9Wur9S/Wf1O31ToP1VwMM5A6HgWvdZVRUz7PS0Gy+yvEx/Us9J/p1
etfX61ja7X11f4K3+bVR/wBXeldLxcvO6t0vpGXiYuPZkOOLgMosb6Q9RzG1X25ld/q17/d6+L6L
6/8ADev+rxs+r3T8A1ZXUek9HtxbrqqHY+PgtbZU7JsZjUFuVa57M1lV91Vdv6pgepTvyv0fpfYr
s/C6ZVfg9Hy7OjdD3dcbWyqluGAKHPx7c/7VZeS77Uz0sWz/ACf6GL77fs/7S/Q/a7tfpH1f6BkH
Mxszo/TH5GBkDHfdVh11ss3U4+a17aLPtD6drMz0dv2i7+a9X/CelXS6t07p/T6vrXTgY1OJU7od
b3V0VtraXEdYaXllTWt37WtXZr//0e/6N/yj13/w+z/2x6as/on1h6BhYuRjZnU8TGyK8/qG+m2+
tj2zm5b27q7Hte3cx25LqPXOgX5WPnYP1h6Zj5ePXbQDfbXdWa7jRZb+iry8Oz1fUw6PTs9fZs9X
9E/f+iq4+b0BubXm5X1k6ZbaMv7daK311tdZ9lu6Rsr35mQ6qr7M7Ef7vWf69OR+k9PKrqxNDC69
9VcXJz7/ANuYD/t+Q3I2/aKRs20Y2Fsn1Xb/AOiepu/4RZ+Lm9A6fi4bOm/WTpleXjYlGDfbe+u2
u6vHDvRf9nZmY9lNtdllzq/TytmzItZfXkfq1mOWvP8Aqq27FybPrBgPyqst2dlWevSBbY7Gt6Zs
rr9f9WqqptpbT/PP9LG/T2X5Fl2Uq78roRpx+n1fWjp1XSsK7GtxscPpNuzFtqyasS/LflFtuOxt
PpVOZjU5X9H+0ZOV6eT9sNn5/wBW7cp2Th9c6Ow2XMyrK8w1ZTRkVMbj05mLtzMN+NkNorrqd77P
5qr0fQt+0vyT9G6z9Wum0Gl3XumFh+hjYz8bGxqtXOd9kx67LLmetv8AUv8AtGXk/pvfV6P80qV+
Z0WzFy+mV/WbpTOlZzsg3VudW7IDcx9l+Y2rLGfXQ1+/Ju+zPdgWej+i9WvJ2fpTWZ31bu6d1jEu
+sXTjb1prhZay2pra3PxKOmvcyl2TY5zN2N6+z1v8J6Pqf4ZXc3r31VysnAv/bmAz7BkOyNv2ik7
91GThbJ9Vuz+l+pu/wCDWf8AbegfZf2R/wA5OmfsL0/s/wBl31/aPs8bPsf2/wC2en6Xp/q3q/Yv
tf2T/tT9t/X0WzP+qrrsrJr+sGAzKty252LZ69JFVjcarpmyyv1/1mq2mq5t38y/0sn9BZRkV05S
n03rHQsfqGV1DN+snTsq/LpopLK7Kaa2Ch2S9vot+0ZFuyz7X7vWuuf63qfpfRsqx8eF3V+jn7Dk
1fWbph6nh47sa3JvdU+u0W/Z35Nv2WjLxPStsuwqbK9mR6VTPVr9Kz9G+quMzou92WfrN0o5xyW5
zLA6sUi8Y7+k2bsf7f6rsd3T/S2Vfa/UrzPUyfXsos+x1Rsy+lXZ7OqW/WjpH2+rZ6ZbsFP6JuVT
TvoPUX2u/RdV6l6v60z1LPsP819lvrzrFfVumC3My7PrR0oZuXjDGbdSamNrNRtfhXspvzsre+m3
My3Xssfsyf1b+j+hd9qPmdc6A7KOd036w9MxsuyttF5vtrvrfXWbLKf0TMvEsZbTZfd6dld+zZfb
69V36t9mjb1joT24+Sz6ydO/auM2xgyn2Uuqcy9zLMjHdh15FLvs+6mj7P8ArX2qr7NR6uXk/rf2
sTM76tvzsbqeZ9YunW51NwstfXbVXW6tlObiUY1NLsm51LK3dTvyXW23ZN1l3qf4D7PViyys/wCq
uRh9bxf+cGA39t7/AH+vSfS34tHTfo+v+m2/ZvW/wX0/T/4Rav8Azs+qv/lzgf8AsVT/AOlFVp6t
0rqX1qwv2dmY+Z6WBm+p9ntZbt3XdM2b/Sc/Zv2P2roEkkkkkkklzPRPrD0DCxcjGzOp4mNkV5/U
N9Nt9bHtnNy3t3V2Pa9u5jtypdRyuhZOFm9Mw/rR07D6f1Bt/qsL6bbWPyfUsyPQyH5TGfZ7r7X2
20249136bIrxsrF/VfsduzqH1Quo6xjXdewjV1pzjZsyaWura/Go6c9rHOssa5+3G9Xfs/wn82hH
rHT78rFvzvrP0ewYV3r0tpDapcWWYtosdZ1LJ3MdiZOS2vbs9PI9C/8ASVU2Y1+Y3qnRcu7HxD1O
vAw8XIoyBS7PwXYVZxra8n08AY1v7TyarX1eli4/UPs+Hi41vrsxce3CwcFbF/Wui15V2T0r6x9K
xjluFmVXkPryGusaxmOy6r0s3CfS91FNVVrd9tP6Gn0q6bftD8ldM6h9UOm5d+RV17CsGRTXW8Py
adxsbdm5uRkve2xrN+Vf1Kx/pVU001f4H9F+iqruyfqqMYtq6/0w5IszSH32U20upz73ZmVhZOJ9
pr9ar+Z97L6bPUx6/wDtPZkYl0+l9R+r+FlfaH9f6PWNrWOqwG42K21tbPRoZmOtyc++xmIzb9j+
z3Yno/Q/TVexlrqHXfq3fbVmYfXunY+djtfXVbZdVbWa7TW6+m6huRQ57Huoota6q+i6u6iv9J6H
2jHvpYuX9XaspuXk/WbAyLvt56hYfVoYCThHpH2etrbzsqZPq07/AFbfS/QXevb+tvLZ1npVOZlZ
HTPrL0ihmbY2+9mSWXn1G11Yn6KynqGDsq9HFp/Rvrsf6vq/pf8AB1Z9vWOhdNoxMbB6pXYcXHbi
15vT8vp7bnU1FzaMbPx+r3fZbfSq9F1WTV6ln2j7d6VXTab/AEcqxg5f1ew8HG+z/WDp1PUsd2S5
ltmSzJrDMy45uTiXerkUZGYxj/R25frY2Vbdi13v/R25OJaZ+d9W8hj7cz6xdOszrbsSy2+u2plf
p4OQ3OoxqcZ2Ta6tjnevuttyL7vWybLP5hmPi03bOvfVWzquP1H9uYA+z49+P6f2in3eu/Ft37/V
9vp/Yvo7P8KqV/VOkvt6fmV/WrpwzsHGsx7bbHUOrvdccV11t1FeTQ6pm7D9VtWPfV+mfX+m9Cqz
HyFkZn1Yv6dbjn6x4VeZlZNGbk5rL6JNtFmNa00Y9lttNTG04NONjts+0emxldmT9tu9ay+GVm9A
6hi5jOpfWTplmXk4l+DRbQ+uqumvIDfWf9nfmZFl1tlldLrPUytmzHqZRXj/AKzZkWKOsdCdlU3d
S+snTsxuE4vww2ymlwe5j8f7RmPbkWMyMj7PbbX+r04WL+nvs+yf0X7KXJ639WMyrJoyvrBhOrtu
ruxdmRQ11BqFFlGx297b31Z2P9t/T1vZ+k+z21WUITetdFyqsjH6z9Y+lZeLkUvodj4768drm2jZ
abXvzcy/fs9lXoXY2z1LvU9b9D6EB1fo9766+pfWbpmVhUWMtZWx1VVz30ubdiuy8huXZVZ6dtde
RZ9kxMH1citn83ierh2rFz/qrj4fRMX/AJwYDv2Js9/r0j1dmLf036Pr/od32n1v8L9D0/8AhFbw
uvfVXFyc+/8AbmA/7fkNyNv2ikbNtGNhbJ9V2/8Aonqbv+EWZ1bqPT+oVfWu7AyacupvQ62Ososb
Y0OA6w4sL6nObv2uauzX/9Lv+jf8o9d/8Ps/9semrWSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSWT9bP/Er1n/whlf+ebFrL//T7/o3/KPXf/D7P/bHpq1kkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkklk/Wz/xK9Z/8IZX/nmxay//1O/6
N/yj13/w+z/2x6atZJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJZ
P1s/8SvWf/CGV/55sWsv/9XtcZ3WKuqdY/Z1GJl1WZbHWG3JtofW/wCyYLPRdW3Ayq3/AKNld3qV
3/4b/SK19p+tX/ldgf8Asdd/8ikvtP1q/wDK7A/9jrv/AJFJfafrV/5XYH/sdd/8ikvtP1q/8rsD
/wBjrv8A5FJfafrV/wCV2B/7HXf/ACKS+0/Wr/yuwP8A2Ou/+RSX2n61f+V2B/7HXf8AyKS+0/Wr
/wArsD/2Ou/+RSX2n61f+V2B/wCx13/yKS+0/Wr/AMrsD/2Ou/8AkUl9p+tX/ldgf+x13/yKS+0/
Wr/yuwP/AGOu/wDkUl9p+tX/AJXYH/sdd/8AIpL7T9av/K7A/wDY67/5FJfafrV/5XYH/sdd/wDI
pL7T9av/ACuwP/Y67/5FJfafrV/5XYH/ALHXf/IpL7T9av8AyuwP/Y67/wCRSX2n61f+V2B/7HXf
/IpL7T9av/K7A/8AY67/AORSX2n61f8Aldgf+x13/wAikvtP1q/8rsD/ANjrv/kUl9p+tX/ldgf+
x13/AMikvtP1q/8AK7A/9jrv/kUl9p+tX/ldgf8Asdd/8ikvtP1q/wDK7A/9jrv/AJFJfafrV/5X
YH/sdd/8ikvtP1q/8rsD/wBjrv8A5FJfafrV/wCV2B/7HXf/ACKS+0/Wr/yuwP8A2Ou/+RSX2n61
f+V2B/7HXf8AyKS+0/Wr/wArsD/2Ou/+RSX2n61f+V2B/wCx13/yKS+0/Wr/AMrsD/2Ou/8AkUl9
p+tX/ldgf+x13/yKS+0/Wr/yuwP/AGOu/wDkUl9p+tX/AJXYH/sdd/8AIpL7T9av/K7A/wDY67/5
FJfafrV/5XYH/sdd/wDIpL7T9av/ACuwP/Y67/5FJfafrV/5XYH/ALHXf/IpL7T9av8AyuwP/Y67
/wCRSX2n61f+V2B/7HXf/IpL7T9av/K7A/8AY67/AORSX2n61f8Aldgf+x13/wAikvtP1q/8rsD/
ANjrv/kUl9p+tX/ldgf+x13/AMikvtP1q/8AK7A/9jrv/kUl9p+tX/ldgf8Asdd/8ikvtP1q/wDK
7A/9jrv/AJFJfafrV/5XYH/sdd/8ikvtP1q/8rsD/wBjrv8A5FJfafrV/wCV2B/7HXf/ACKS+0/W
r/yuwP8A2Ou/+RSX2n61f+V2B/7HXf8AyKS+0/Wr/wArsD/2Ou/+RSX2n61f+V2B/wCx13/yKS+0
/Wr/AMrsD/2Ou/8AkUl9p+tX/ldgf+x13/yKWf8AWG36xW9A6nVk4mBjY9mJe27I+2Xv9Nhre2y7
0mdL32+kz3+m36a6Zf/Z

------=_NextPart_000_0003_01C07CC8.13C00A70--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 10:26:29 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10573
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 10:26:28 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5DB9844352; Fri, 12 Jan 2001 09:22:30 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mip.miptel.com (unknown [210.121.191.65])
	by lists.bell-labs.com (Postfix) with ESMTP id AC13144336
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 04:21:44 -0500 (EST)
Received: from arnold ([210.121.191.94])
	by mip.miptel.com (8.10.1/8.8.7) with SMTP id f0CANou22402
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 19:23:50 +0900
From: =?ks_c_5601-1987?B?wMzI8byu?= <hslee@miptel.com>
To: <sip@lists.bell-labs.com>
Message-ID: <BPEHLGEAGAFJCAHHDKDEMEAKCDAA.hslee@miptel.com>
MIME-Version: 1.0
Content-Type: multipart/related;
	boundary="----=_NextPart_000_0000_01C07CCD.A19B8E00"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [SIP] [SIP]How do the proxy server search the next proxy server ?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 19:26:58 +0900

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C07CCD.A19B8E00
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0001_01C07CCD.A19B8E00"


------=_NextPart_001_0001_01C07CCD.A19B8E00
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

DQoNCg0KDQpwcm94eSAxIDogc2lwLmFhYS5jb20NCnByb3h5IDIgOiBzaXAuYmJiLmNvbQ0KVUFj
IDogYXJub2xkQGFybm9sZC5hYWEuY29tDQpVQXMgOiBkcmFnb25AZHJhZ29uLmJiYi5jb20NCg0K
DQoxKSBXaGVuIFVBYyBzZW5kcyBhIHJlcXVlc3QoSU5WSVRFKSB0byBwcm94eSAxLCB3aGF0IGlz
IHRoZSBSZXF1ZXN0LVVSSSBpbiB0aGUgUmVxdWVzdC1MaW5lID8NCiAgICAoYSkgSU5WSVRFIDog
c2lwOmRyYWdvbkBzaXAuYmJiLmNvbQ0KICAgIChiKSBJTlZJVEUgOiBzaXA6ZHJhZ29uQGRyYWdv
bi5iYmIuY29tDQogICAgV2hpY2ggaXMgdGhlIGNvcnJlY3QgYW5zd2VyID8NCg0KSWYgKGIpIGlz
IHJpZ2h0LA0KMikgSG93IGRvIHRoZSBwcm94eSBzZXJ2ZXIgMSBzZWFyY2ggdGhlIG5leHQgcHJv
eHkgc2VydmVyIDI/DQoNClBsZWFzZSwgQ291bGQgeW91IGNvcnJlY3QgbWUgPw0KSGFwcHkgbmV3
IHllYXIgYW5kIGhhdmUgYSBnb29kIGhlYWx0aHkhISENCiAgDQoNCg==

------=_NextPart_001_0001_01C07CCD.A19B8E00
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgY29udGVudD0idGV4dC9o
dG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxN
RVRBIGNvbnRlbnQ9Ik1TSFRNTCA1LjAwLjMxMDMuMTAwMCIgbmFtZT1HRU5FUkFUT1I+PC9IRUFE
Pg0KPEJPRFk+PElNRyBhbGlnbj1iYXNlbGluZSBhbHQ9IiIgYm9yZGVyPTAgaHNwYWNlPTAgDQpz
cmM9ImNpZDo3Njg0NzI2MTBAMTIwMTIwMDEtMmU1OSI+PEJSPg0KPFA+PEZPTlQgc2l6ZT0yPjxC
Uj48QlI+cHJveHkgMSA6IHNpcC5hYWEuY29tPEJSPnByb3h5IDIgOiBzaXAuYmJiLmNvbTxCUj5V
QWMgOiANCmFybm9sZEBhcm5vbGQuYWFhLmNvbTxCUj5VQXMgOiBkcmFnb25AZHJhZ29uLmJiYi5j
b208QlI+PEJSPjxCUj4xKSBXaGVuIFVBYyANCnNlbmRzIGEgcmVxdWVzdChJTlZJVEUpIHRvIHBy
b3h5IDEsIHdoYXQgaXMgdGhlIFJlcXVlc3QtVVJJIGluIHRoZSBSZXF1ZXN0LUxpbmUgDQo/PEJS
PiZuYnNwOyZuYnNwOyZuYnNwOyAoYSkgSU5WSVRFIDogDQpzaXA6ZHJhZ29uQHNpcC5iYmIuY29t
PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyAoYikgSU5WSVRFIDogDQpzaXA6ZHJhZ29uQGRyYWdvbi5i
YmIuY29tPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBXaGljaCBpcyB0aGUgY29ycmVjdCBhbnN3ZXIg
DQo/PEJSPjxCUj5JZiAoYikgaXMgcmlnaHQsPEJSPjIpIEhvdyBkbyB0aGUgcHJveHkgc2VydmVy
IDEgc2VhcmNoIHRoZSBuZXh0IHByb3h5IA0Kc2VydmVyIDI/PEJSPjxCUj5QbGVhc2UsIENvdWxk
IHlvdSBjb3JyZWN0IG1lID88QlI+SGFwcHkgbmV3IHllYXIgYW5kIGhhdmUgYSANCmdvb2QgaGVh
bHRoeSEhITxCUj4mbmJzcDs8L0ZPTlQ+IDwvUD48L0JPRFk+PC9IVE1MPg0K

------=_NextPart_001_0001_01C07CCD.A19B8E00--

------=_NextPart_000_0000_01C07CCD.A19B8E00
Content-Type: image/jpeg;
	name="ques copy.jpg"
Content-Transfer-Encoding: base64
Content-ID: <768472610@12012001-2e59>
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAgEASABIAAD/7QloUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAAR/+0AAIA
AgBH/7QAAgACOEJJTQQNAAAAAAAEAAAAeDhCSU0D8wAAAAAACAAAAAAAAAAAOEJJTQQKAAAAAAAB
AAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP0AAAAAAASADUAAAABAC0AAAAGAAAAAAABOEJJ
TQP3AAAAAAAcAAD/////////////////////////////A+gAADhCSU0EAAAAAAAAAgABOEJJTQQC
AAAAAAAEAAAAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBBQAAAAAAAQAAAACOEJJ
TQQMAAAAAAhDAAAAAQAAAHAAAAA4AAABUAAASYAAAAgnABgAAf/Y/+AAEEpGSUYAAQIBAEgASAAA
/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwR
DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwR
EQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAOABwAwEiAAIRAQMRAf/d
AAQAB//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQAC
AwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIz
NHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV
5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEi
EwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N1
4/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A9JxM
TFfi1OdUxznMBJIBJJ1JJKL9iw/9Cz/NCWF/Q6f6jfyI6SmtZjYFTC+yutjBy5wAGuiFPR/GjXza
jZv8009hbUT5APZJWYXerdda7BdvdPvNu3dO2mK527Paxj7H/ufpavzElN0u6MOTQPm1H+xYf+hZ
/mhUGvIwXsbV6PrVWufUXb3tf7WU1/8AXGf4Nq1klIPsWH/oWf5oS+xYf+hZ/mhHSSU134uCxjnv
qraxoJc4gAADlzig7ujeNGnOrUfOBOFeACSa3QBqeFnXXeplve7Cc/YHBt3qABwBDg2tjhtc+30K
tnqez/hP55JTaLujDk0D/NRxh4TgCKayDqCAFSwrRUB+hOP6hIsa57rCA1ntdv8Aos3We33/AM5/
XV7DaW4dDXAtcK2Ag6EENGiSlvsWH/oWf5oUbcPFbU8ilgIaSDtHgrKHf/M2f1T+RJT/AP/Q9Owv
6HT/AFG/kR0DC/odP9Rv5EdJSKy12/0ao9Ut3EkEtaOGudEfSd9Fih9kDtbbbXuPcPLB8mUljVXb
lOoDrfRsvddbY1zqwDtFZNVTXSW7Paz+op2dScx20YeTZoDuaxsat3/nPb/xbv8AhElJfTvol1b3
XMH+CfBdH/B2e3/wbfv/ANIxGrsZaxtlZ3McJafIqtZnvZuIxb7Ns/Qa2TE/RD3s/dTturostZts
IL94DWPcBuAc6NjT+f70lNpJV/ttX7lv/bVn/kEhmVExst1/4Kz/AMgkpJdaKmTBc5xhjBy537oU
DRZaZuscB2rrJaB/1xu217v7Wz/gln4/WftdjrW4eZUMc2MNF1Jre8h9dTb6G2fz1Oxz37mO/m1Z
d1G0VtezEudu3S2ACC1zWcfy/e9v9RJSb7M5nuote137thNjT8RY7e3/AK3Yz+2iVWl5c1w2PYYc
2Z0/NcP5LkEZr/Sreca4Oe0ucwNBLdv5rvd+d/g1Cu51l1GQan0G4OrdVZAdoPWrc/Y6xvs22M/6
6kpuod/8zZ/VP5ERDv8A5mz+qfyJKf/R9Owv6HT/AFG/kRiQBJ0AVCrqGPjYlPqyBLKQ4CZseG+n
WPztz9yHZ1bEueGy4VAB7mhp3O127XN+kyuuW+vu/wDPfqpKX6VnX3WZHrYr8Sh1724psIJeGhu+
3Yz2V132epZj/pLfV/nfZ/NrTWe7rPTntYHbi21osYHMOrPd+k2/ufonP9yEczFbv9O6+pjGl7xA
c0AEB3uvbZ++z9Hv/sJKdKyxlTC95gD5kk8NaPznOUcdlga59ullp3ubMhugaK2/1Wt/z1Rx8/p5
c9zHWXPrI9R7pcW62MLv3Kv5q31PSaj1dUxrW2PYHltOtpLSNsF7H/S+l6b6rGP2fuJKbiSSY6ap
KQ3jY9l4aXbJa+Odjvpe38/3srRmua9oc0hzXCWuGoIPcKk/rOExzWvLmlwa4EtMQ+Nvu+j+ez/t
xV7up9NYXPFttDmx6mwHQucWhr6nB9fqvsbZ/g/W/R2JKdZVqXNyMg5DDNdTTUwwRJcWvsd7h72e
yr03M/4RUzn4LLjXkW3WvbtGx4hs2b2Vt2VtZXY6yyqytjHep+mYh9Q6pZ9lsv6PWLs6tjXU1WzX
VY1zmsax1ga7979B+5Z9N9VD7klOyh3/AMzZ/VP5FWr6viWhxrDzs2gjaQZfs2iD9L+ep/7drUXd
UxLm2117i5rfd7TA3bdn/n2t/wDxb0lP/9L0XHx8F9FT7CN5a1x95HuDQzftDtrbPb9NT+ydNPJB
1B/nHcj6J+n+avmJJJT9OjE6YI27RAgRYRAH5rff9FN9i6X4N4j6Z4ndt+n9HcV8xpJKfpz7F0oG
QGAzMh5Go7/STjE6aG7AQGRGwWO2x+6Wb9u3+SvmJJJT9TevT/pG/eEvXo/0jfvC+WUklP04MLpQ
EQ3gN/nDw36Dfp/mfmJNwelMrFTQ0VgBoYHnbtA2tbt37drWr5jSSU/TlmD0qxr22BrxZpZueTu0
2e+X+/2HYn+x9Mjb7Y5j1DE/DevmJJJT9OfYulgEANAPIDzrru19/wC8dyazF6cKnbSNAXAeo6JB
9T6O/wB3v96+ZEklP//ZADhCSU0EBgAAAAAABwABAAAAAQEA/+IBoElDQ19QUk9GSUxFAAEBAAAB
kEFEQkUCEAAAbW50ckdSQVlYWVogB9EAAQAMABIAIQATYWNzcE1TRlQAAAAAbm9uZQAAAAAAAAAA
AAAAAAAAAAAAAPbWAAEAAAAA0y1BREJFAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAFY3BydAAAAMAAAAAkZGVzYwAAAOQAAABxd3RwdAAAAVgAAAAUYmtwdAAA
AWwAAAAUa1RSQwAAAYAAAAAOdGV4dAAAAAAoYykgMjAwMSBBZG9iZSBTeXN0ZW1zIEluYy4AZGVz
YwAAAAAAAAAWR3JheXNjYWxlIC0gR2FtbWEgMi4yAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABY
WVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAY3VydgAAAAAAAAABAjMAAP/u
AA5BZG9iZQBkgAAAAAD/2wBDAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwM
DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAALCAD2AekBAREA/90ABAA+/8QAogAAAQUBAQEB
AQEAAAAAAAAAAwABAgQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIG
FJGhsUIjJBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieU
pIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/f/2gAIAQEAAD8A7eqrqXUOpdVA
6rk4lWJksoppoZiloacXDynEuysPJuc912Tb/hVY/Y3Uf/L3P/zMH/5GpfsbqP8A5e5/+Zg//I1L
9jdR/wDL3P8A8zB/+RqX7G6j/wCXuf8A5mD/API1L9jdR/8AL3P/AMzB/wDkal+xuo/+Xuf/AJmD
/wDI1L9jdR/8vc//ADMH/wCRqX7G6j/5e5/+Zg//ACNS/Y3Uf/L3P/zMH/5GpfsbqP8A5e5/+Zg/
/I1L9jdR/wDL3P8A8zB/+RqX7G6j/wCXuf8A5mD/API1L9jdR/8AL3P/AMzB/wDkal+xuo/+Xuf/
AJmD/wDI1L9jdR/8vc//ADMH/wCRqX7G6j/5e5/+Zg//ACNS/Y3Uf/L3P/zMH/5GpfsbqP8A5e5/
+Zg//I1L9jdR/wDL3P8A8zB/+RqX7G6j/wCXuf8A5mD/API1L9jdR/8AL3P/AMzB/wDkal+xuo/+
Xuf/AJmD/wDI1L9jdR/8vc//ADMH/wCRqX7G6j/5e5/+Zg//ACNS/Y3Uf/L3P/zMH/5GpfsbqP8A
5e5/+Zg//I1L9jdR/wDL3P8A8zB/+RqX7G6j/wCXuf8A5mD/API1L9jdR/8AL3P/AMzB/wDkal+x
uo/+Xuf/AJmD/wDI1L9jdR/8vc//ADMH/wCRqX7G6j/5e5/+Zg//ACNS/Y3Uf/L3P/zMH/5Gpfsb
qP8A5e5/+Zg//I1L9jdR/wDL3P8A8zB/+RqX7G6j/wCXuf8A5mD/API1L9jdR/8AL3P/AMzB/wDk
al+xuo/+Xuf/AJmD/wDI1L9jdR/8vc//ADMH/wCRqX7G6j/5e5/+Zg//ACNS/Y3Uf/L3P/zMH/5G
pfsbqP8A5e5/+Zg//I1L9jdR/wDL3P8A8zB/+RqX7G6j/wCXuf8A5mD/API1L9jdR/8AL3P/AMzB
/wDkal+xuo/+Xuf/AJmD/wDI1L9jdR/8vc//ADMH/wCRqX7G6j/5e5/+Zg//ACNS/Y3Uf/L3P/zM
H/5GpfsbqP8A5e5/+Zg//I1L9jdR/wDL3P8A8zB/+RqX7G6j/wCXuf8A5mD/API1L9jdR/8AL3P/
AMzB/wDkal+xuo/+Xuf/AJmD/wDI1L9jdR/8vc//ADMH/wCRqX7G6j/5e5/+Zg//ACNS/Y3Uf/L3
P/zMH/5GpfsbqP8A5e5/+Zg//I1L9jdR/wDL3P8A8zB/+Rqpdcw+rdP6L1DPp65mutxMa6+tr68I
tLq632sDw3p7XbNzf3l0a//Q7/o3/KPXf/D7P/bHpq1kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkklk/Wz/xK9Z/8IZX/nmxay//0e/6N/yj13/w+z/2x6atZJJJJJJJ
JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJZP1s/8SvWf/CGV/55sWsv/9Lv
+jf8o9d/8Ps/9semrWSSSSSSSSSSWZd9Z/q3Ra+m7q2FVbU4ssrfkVNc1zTtex7HWbmva5Q/52fV
X/y5wP8A2Kp/9KJf87Pqr/5c4H/sVT/6US/52fVX/wAucD/2Kp/9KJf87Pqr/wCXOB/7FU/+lEv+
dn1V/wDLnA/9iqf/AEol/wA7Pqr/AOXOB/7FU/8ApRL/AJ2fVX/y5wP/AGKp/wDSiX/Oz6q/+XOB
/wCxVP8A6UVvB6t0rqW/9nZmPmelHqfZ7WW7d07N/pOfs37H7VbSSSSSSSSSSSSSSSQcrLxcKh2T
mXV42PXG+61wYxskMbussLWN3PdtWf8A87Pqr/5c4H/sVT/6US/52fVX/wAucD/2Kp/9KJf87Pqr
/wCXOB/7FU/+lEv+dn1V/wDLnA/9iqf/AEol/wA7Pqr/AOXOB/7FU/8ApRL/AJ2fVX/y5wP/AGKp
/wDSiX/Oz6q/+XOB/wCxVP8A6US/52fVX/y5wP8A2Kp/9KJf87Pqr/5c4H/sVT/6UWnTdVfUy6l7
barWh9djCHNc1w3Mex7fa5jmqaSSSSSSSSSSyfrZ/wCJXrP/AIQyv/PNi1l//9Pv+jf8o9d/8Ps/
9semrWSSSSSSSSSSWT9Wv+Trv/D/AFH/ANvsxay5cZvWKuldQ69ZnOsb067PczAFdTan0Yl+TWKb
7PTdlfaHU0enVk03011fq/rYmV6WR9sLd1HqOPb1/qVmQ6zD6I57qcBja2CwNwcbNfXkZLq7rtnr
Xb6PR9F9T/U9b7VT6VFFjJ/afShVm39QszhbkY+PfivrprpH2q6rD34no1Nyqfs9t7LK25OVnfq7
H49v6az7bTDI6h1Gq23ogub+0spzzhZv6MNrquN9tT7cc/8Aajp9VNtePi7LP2p9l9f1fT/a1nSo
5HVM+rA6hg+rHWhkPx8E7W6/anPs6Vk11bd12JhYz/1y70LP+Suqf0n7LZv6BJZON/4quo/+EMH/
AM/dVWskkkkkkkkkkkkkkksn6y/8nU/+H+nf+32GtZZn1iyc3G6aLMGxtOS/JxKWWPZ6jQLsrHxr
N9W6vex1Vz/o2VP/ANHbU/8ASLM6vndT6Li51AzLMu09Mzc7Gyr2UiyqzEFLdm3Hpoxrqnuy6rK9
+PvqfTb6lmTXfWzGt2ftNuVj9Id1Cz1syu/LtzWV0h1baDi1fZMGh9VtVdT7czeyzN/aF9dDLafU
uttrysZMs6sLsvpNOV6+ViV4uXTlXtY11jLbb/Uwsn0KvRZ6n7Puo+2UYv6GjKr/AFWzIxfWyq9n
WOo9RxbOp9JLmYuE1jrMYCu2+8h+Lm5VdLKvX2v/AGc2/GwNl2zqVmf9qo/UvsHUMrQx+oOzertb
hXNt6fRjbr3s2uY+3INVuD6NzN/vpxKr7r697P0PUMC79N636LTSWT9U/wDxK9G/8IYv/nmtaySS
SSSSSSSSyfrZ/wCJXrP/AIQyv/PNi1l//9Tv+jf8o9d/8Ps/9semrWSSSSSSSSSSWT9Wv+Trv/D/
AFH/ANvsxaywcL6suYy6vLy7n42Rk5V9+A1zXY9jb8i7Jqbb6tX2pjPRspZk4lGRVhX7LfWpvZkZ
X2nTr6ZisOdvb6zOpWepk1WgOYf0NOC6vZt/mn04zN7LN/8AhFXp6IG2sORm5OZj0uD6MTINbq2O
YZoe6xlNeXlPx/8ABfbsnK/TbMqz1MyqnIrm/omK/Ay8Jz7P12yy6zIkes2x7vUpuqt2+23A20M6
fZ9PFrxMT/QKFXTbburnqebXSx2O11OIyol5c0k7MvJssrp25DKrLacamtv6mzK6j+tZP2/9DppL
Jxv/ABVdR/8ACGD/AOfuqrWSSSSSSSSSSSSSSSWT9Zf+Tqf/AA/07/2+w1rLP6701/VOnjDY7ZOR
jWvdvdWdlORRlXenbR+lrt9Kl/ovr2fpf8JX9NBf9Xqb8XLozsrIzbczHsxHZVvpCyum0bbasZuP
RRjVbnfpHv8As/qXPZT9o9avGxmU287p7MzZY22zFyqZ9HKo2+owOj1a/wBOy+myq7Y31Kb6bat7
Kr/6Rj491Vf9g478W2jJuuybMl1Zysmws9S5lTxYzEtbVVXj/Yns349uJVRVTbTkZX+Hysi6wuXi
WtyP2jhMbZmtpNHo2WGmqxpfXY05NtdOVbvxdt/2T9G/0/tOV/3J9RLo/S6ul4Qxq9pcXGy17Ghj
S535tdY3enj49QrxcOn1Lfs2FRjY3q2eirySyfqn/wCJXo3/AIQxf/PNa1kkkkkkkkkklk/Wz/xK
9Z/8IZX/AJ5sWsv/1e/6N/yj13/w+z/2x6atZJJJJJJJJJJZP1a/5Ou/8P8AUf8A2+zFO/rT25V2
Nh9PyeoHGcK8iyg47WsscxmR6J+25WG97/Qvot3VMfT+l/nPV9VlcB9YsW5ld2BRkdQx3Vsutuxm
Aiqu1rb6jbXc+nIstfjv9f7HiU5Od6Xpfq36zi+vP9vY7+oMwMSm7MdZTTk+vQGGgUZDraq8g5L7
a6tjfs+/069+RdW/1MSnJ9PI9GbOt4r+k4fVgyz7PnfZfSbA3j7Y+mjH9Ru7Z7H5NfrbX/8AbihT
17HttZ+huZhXODMbqLgz7Pa9x21Nqc212Q1l7/ZjZF+PTi5f6L7Lfd9qw/tM+ndYZ1G65lGNkNpo
supfk2Na2s20WuxbKq5s9a3ds9Vl1dP2bZ+j9f7VXbj1h+sGR1LFpxb8K+uqr7Xi1ZLHV73vZfk4
2M5tNvqNro/R22+pvx8j/gvQs/SrWWTjf+KrqP8A4Qwf/P3VVrJJJJJJJJJJJJJJJLJ+sv8AydT/
AOH+nf8At9hrQy8qjCxbszJd6ePjVutufBO1jAbLHbWBz3bWN/NVKjrT3ZVONmdPyennJca8ey84
7mvsax+R6I+xZWY9j/Qovt3WsZT+i/nPV9Jlip69j22s/Q3MwrnBmN1FwZ9nte47am1Oba7Iay9/
sxsi/Hpxcv8ARfZb7vtWH9pFifWbHyunVdTGJk04eQ7Fbj2WtY02HLsrxmbKvV9ZrKLr2etZZXWy
xn6bC+10+nYrHUet4vT8rHw7WWWZOXXa/FqrALrHUmhjqK9zmfpX/am2f6CqirIyMq7Hx6H2INv1
ixcfDsyMqjIotosprvwywWXt+02MxsaxtWK+9mRVY+z2vxLMj+bvoZ+uUXYy0MW6y+htttFmK90z
RaWF7YJb7jjWZFPu+n7Lljm/rGI3Ez8u5xvzbqabOjxUWV+s5rbGYt1LPtVuR06nflZV7r8jHyKc
XOs+zYlNlT8HeWT9U/8AxK9G/wDCGL/55rWskkkkkkkkkksn62f+JXrP/hDK/wDPNi1l/9bv+jf8
o9d/8Ps/9semrWSSSSSSSSSSWT9Wv+Trv/D/AFH/ANvsxVeqY+S/Ptud0vIuubtGF1LptlFVzKg1
rvs+VZmZeK6/Zm+vf9jspyel21/ZfWput9VVH9Hzacm7LzsXLzsjP9K6/wDZWbZi113MooxMir7P
bn9NY+pz8b1cbJ/S5FjLPQyK6fs1L8jT6R0y3B6g8ihtGK3p2Di0sZYbGtdjuzvVoZZZsvsZSzIo
/TXVV+t/24oY3Rr6+slzz/kzGsszcNmmmTlh9eV7t3rfq+7PyP0v6G39t+lWxn7NpWb076vHDbhd
Ntwc3J+xOoAzHZ9n2J32d1dlWT9idm2Wse30WW14P7M+z1Zn6r632T9eW70PFvxMKyrIbse7LzbQ
JB9l2Vk5NDvaXfTptrel1zFvy8KurHbve3LwrSJA9lOVjZN7vcW/QpqsetBZON/4quo/+EMH/wA/
dVWskkkkkkkkkkkkkkksn6y/8nU/+H+nf+32GtDL+1fZbvsXp/a/Td9n9afT9SD6Xren+k9L1P5z
Z79ixel4+TRn1DA6XkdJwTu+1UX2UHG2bXen9gxMLLzG4mX9p2Pf6NWNi302ZlmV62X9kVLp31eO
G3C6bbg5uT9idQBmOz7PsTvs7q7Ksn7E7NstY9vostrwf2Z9nqzP1X1vsn68tfpPS/8AsVw+j9Sq
/wC0FWJmU7v+BbRkVepS7+uzfVYsqz6u9SyaWZ3UXWZPUcfIYXNps+y2XUY1WVgVNpyMO2lmPblv
zczrFbd9XvzP2TlX141f2imbej22Y9lmP0/JxrbMnpxcc7LOTe6vFy68y36eVn01Y+PS66yrZl+t
dZ6/6t/M/aOoXP8ATMnqjspuV1Ho+W3Mvis2b8R1ONU4tLqKNmc651TdrLMvI9D7TnWV+p6PpVYW
FidAsn6p/wDiV6N/4Qxf/PNa1kkkkkkkkkklk/Wz/wASvWf/AAhlf+ebFrL/1+/6N/yj13/w+z/2
x6atZJJJJJJJJJJZl31Y+rd9r7ruk4Vttri+yx+PU5znOO573vdXuc9zlD/mn9Vf/KbA/wDYWn/0
ml/zT+qv/lNgf+wtP/pNL/mn9Vf/ACmwP/YWn/0ml/zT+qv/AJTYH/sLT/6TS/5p/VX/AMpsD/2F
p/8ASaX/ADT+qv8A5TYH/sLT/wCk0v8Amn9Vf/KbA/8AYWn/ANJpf80/qr/5TYH/ALC0/wDpNW8H
pPSum7/2dh4+H6sep9nqZVu2zs3+k1m/ZvftVtJJJJJJJJJJJJJJJBysTFzaHY2ZTXk49kb6bWh7
HQQ9u6uwOY7a9u5Z/wDzT+qv/lNgf+wtP/pNL/mn9Vf/ACmwP/YWn/0ml/zT+qv/AJTYH/sLT/6T
S/5p/VX/AMpsD/2Fp/8ASaX/ADT+qv8A5TYH/sLT/wCk0v8Amn9Vf/KbA/8AYWn/ANJpf80/qr/5
TYH/ALC0/wDpNL/mn9Vf/KbA/wDYWn/0ml/zT+qv/lNgf+wtP/pNadNNVFTKaWNqqqaGV1sAa1rW
jaxjGN9rWNappJJJJJJJJJLJ+tn/AIles/8AhDK/882LWX//0O/6N/yj13/w+z/2x6atZJJJJJJJ
JJJJBysvFwqHZOZdXjY9cb7rXBjGyQxu6ywtY3c921Z/7f8AV/oPTc/Mj+c/QfZds/R/5Zf0z1t/
u/o3r+n/AIb0/wBF6i+2/WS330dLx66j9FmXmGu4RofVrwsTqOM33fQ9PNu/R/6Oz9Exen9aqv0n
2jAzI/7T+hdi7p0/pn2rqfo7Pp/0G/1P5r9H/PVr9o9do/pXSPW3fQ+wZNdsR9L1/wBpN6Ns/wCC
9H7T/hPU9H9H6q/5zdJr0zn2dMI0cc6t+PWH/nUMzb2twMi36X9Eysj1WMsuo9Wn9ItZJJJJJJJJ
JJJJJJJJJJJJJUc3rPTsG0UXWOfkubvGNRXZkX7CS31zi4bL8huPvb6f2j0vR9T9H6m9V/2v1O/2
4fSMj361X5dlOPSW/S32hlmV1Kjez6FdnTPX9T9HkVY/6T0l/wBlV/8A3A6dt/47O3z/AO4T7P6f
/oT6u/8AwPpfpVu+tVHs9PAz519X1LsKP+D+z+l1nf8Avet9qr/c9D9H6lq/bmTX78ro+fj0j6du
2i/b+7+r9Nys3Ns3O9v6HFt/fs/RepYreD1TA6hvGLbutpj1qHtdVdXun0/tGJe2rJx/Va3fV61T
PVr/AElf6NW0kkkkkkkkkkklk/Wz/wASvWf/AAhlf+ebFrL/0e/6N/yj13/w+z/2x6atZJJJJJJJ
JJJZP7Xvz/b0KuvJpOh6m94+yA8P9D0S67qFtO5v6Or0MOz9NjftPHyqbKkbF6Ji03tzMh9mfnMn
Zl5RD3skGt32auttWLhb6v0V32HHxvtP/an1rPetBJJJJZP7E+w/pehv+x7df2fMYdkf4P0Ntn7P
3TZ+m6a2j9Ys+1ZlHUP5hGxersfe3Cz6/sGe+fSx7HtcLg0F1luBa0/rVTNj/wAynMpq9O3Lw8X1
6d+gkkkkkkkkkkkkkkkkkq+b1DCwKhbmXNpa92ysHVz3kFzKMeps25GRZt/RY9LLLrf8HWqP2TqX
U/d1B9nT8X83Cxbttjwfc1+bm0NruotZ7P1bpuT6TH12+pndRx7/AE6r2F07p/T6jTgY1OJU5291
dFba2lxAaXllTWt37WtVhJJJVM7peB1DYcqrdbTPo3sc6q6vdHqfZ8uh1WTj+q1uy30bWerX+js/
Rqp63Vume29lnVcManKZs+1sB9z/AF8KmvHpyaqof+kwP1x/6HGr6ZkW+plW6GLl4ubQ3Jw7q8nH
snZdU4PY6CWO22VlzHbXt2oySSSSSSSSSSyfrZ/4les/+EMr/wA82LWX/9Lv+jf8o9d/8Ps/9sem
rWSSSSSSSSSWT/y5/wCmb/28/wDlV/8AFX/01f8AKuskkkkkkkg5WLRmUOx8hu+p8SJLSC0h9dld
jC2yq2qxrbKbq3erTb+lq/SKr03Kva93TuoOnOq3ursIAF9AdtpymbAyt9rK3019QZXXT6GZ/wBp
6sTJwfX0EkkkkkkkkkkkkkklXzc2rCqD3h1lljvToorg2W2EFzaaWuLW79rXvc572U00ssyMiynH
pttZX6Z0z0NudnNrt6xbWG5WU0TE7XvxMR72tsq6fVY39BR/6EZHq5luRkW6CSSSSSSSzM/p7qbX
dU6ZS0dQ3MOS1u1v2qppay2i/dsZdkV47Xfs626yr7PkenX9oqwrsyu67i5VGZQ3Ix3b6nzBgtIL
SWWV2VvDbKrarGurupsb6tNv6K39IjJJJJJJJJJLJ+tn/iV6z/4Qyv8AzzYtZf/T7/o3/KPXf/D7
P/bHpq1kkkkkkkklk9X/AF++voTdacmt7+pkcjEg0+hvG70beoXO9Kv2/pMOjqf2a6nKx6rFrJJJ
JJJJJJKvm4VWbUGPLq7K3epRfXAsqsALW3UucHN37XPY5r2PpupfZj5Fd2PdbU8PR823MwgckNZm
0ONGbWyQ1t9ftsNbHl1rce/25WH6v6S3Cvxr/wDCq8kkkkkkkkkkkkkoXXVUVPuue2qqppfZY8hr
WtaNz3ve72tY1qz+j025DR1bNY5uXktPo1WAtdj473epRi+i7+YyHVNos6n9P1M32es/GxcKujTS
SSSSSSSSWT1L/Jl7erU+zHfYxvVW/mmsj0K8/boyu3Cf6H2rKc+tn7JryPtHr/ZMH0NZJJJJJJJJ
JZP1s/8AEr1n/wAIZX/nmxay/9Tv+jf8o9d/8Ps/9semrWSSSSSSSQcvKowsW7MyXenj41brbnwT
tYwGyx21gc921jfzVV6Ji304r8jMbszs+w5WWyQdj3htdeNurPpP+xYtWPg+tV/Sfs32n+cuetBJ
JJJJJJJJJZPUP1DquN1QaU5WzAzfLe8/su/8536LNyLMP0qme/8Aan2jIs9LCWskkkkkkkkkkkkk
snrX61fg9HGrMyx1uYzucTHAsuHu/RvqvzLOn4OVQ71PXw8zI/R/zl1OskkkkkkkkkkoXU1X1Ppu
Y22q1pZZW8BzXNcNr2PY72uY5qz+gXWnCfh5D3WZPTbn4ljnkue5rIfhXX2/4XIyenW4eVkWM/w1
9n8y/wDQ16aSSSSSSSSyfrZ/4les/wDhDK/882LWX//V7/o3/KPXf/D7P/bHpq1kkkkkkklk9f8A
0v7NwePtmfR+k52/Zd/Wfo/n+t+zPs30v0fr+t/g/Ss1kkkkkkkkkkklR65hW9Q6L1DApLW25eNd
RW58hodZW+pheWhztm537qN07Nq6h0/Gz6Q5tWXTXfW18BwbY1trA8NLm79rv3lYSSSSSSSSSSSS
WT0n9a6l1Pqf5jrG4OO4aB1eH6gte5rvf6rOp5PU8Z35j6sej0q/8PfrJJJJJJJJJJJLJu/VPrJR
edKuqY5xHuOv6bGNmbhVVhvub6uNf1ay57/0f6rR/NWf0jWSSSSSSSSWT9bP/Er1n/whlf8Anmxa
y//W7/o3/KPXf/D7P/bHpq1kkkkkkklk5v6X6ydLofrVXj5mWxvEXVnEwq7ZHu9uN1HNr2fzf6b/
AEldWzTuuqoqfdc9tVVTS+yx5DWta0bnve93taxrVlXfWLEfj3txnuxcoU2Ox39Sx8nExy9jH2j1
LsunGa5jGsdddXU/1vs1V93+CsVjM690zCyjhXPsdlitt32eim6+z03mytt3pYlV1npepS9lln0K
X+l6v9Io9S7TdVfUy6l7barWh9djCHNc1w3Mex7fa5jmrPu+sXSqbX1vfdtqcW25Dce92OwtO271
c+ul2DWzHcHsybH5GzF9O37R6fpWKeV13p+Le7HeMi22uPUGNjZGSGEgPFdtmFRkV1W+m5lno2O9
X0rKrf5u2tLI690yj04fZk+tW25n2Sm7L/Rv/mbnfYKsn06r9r/Qss9l/p2+j/NWK1i5VGZQ3Ix3
b6nzBgtILSWWV2VvDbKrarGurupsb6tNv6K39IquV17pmJe6i99k1R69jKbrKapAf+t5dNVmLiba
nMvs+03VeljvZkW/oX+ollde6ZiXuovfZNUevYym6ymqQH/reXTVZi4m2pzL7PtN1XpY72ZFv6F/
qJZnXumYWUcK59jssVtu+z0U3X2em82Vtu9LEqus9L1KXsss+hS/0vV/pFHqLF6/0nMvbRi3+r6k
+jc1jzRaQC99eLnbPsWVaxrLN9OPkW2s9HI/7j3+noLJ+q/s6LTjD6GDZfg1Hua8O+7p+O+z/hX0
41brtvs9X/B1/QWskkkkkkkkkkqmR1bpWLlV4WTmY9GXft9HHstYyx+8+nX6dT3Cx++wbGbfz1bW
T9VPd9W+nXnW3Lx2Zd7v3rskfbcu2Pot9XJvts2M/Rs/wf6NGyuu9Pxb3Y7xkW21x6gxsbIyQwkB
4rtswqMiuq303Ms9Gx3q+lZVb/N21qH7bwqMfKz8vMxv2fXdU2nIqfua1l7MX0ftbxuYx9l+V6jb
P5n7FdjX/v2Kxg9Uw8/eMc2NfVG+q+qyiwB0+nZ9ny66LvSs2WNru9P0rH1W/wCisVfrXWG9Kf09
1ha2jLyTj3EhznR9nysipmOyv32ZFuRj001VNZa+71PRqq9aytC6h9YsWnpR6ljva2urJxqMn7S1
9Jqbbfj0XnIpyPs92M9mLk/aK/Xaz2ejke+hLN+sNI6L1PPwd32np+NbkCjJptodLa7LaX2Y2SzG
yPs9r6ns9Vvss9O6uu3fVYrWF1np2faasaxznbd7C6uyttrAQ034dtzK6s3H99f6xiPvp/TUfpP0
9O+3ddVRU+657aqqml9ljyGta1o3Pe97va1jWqphdYwc6000+tXaG7xXkUXYznNBDXvqZm1Y7rmV
ufX6vo7/AEfVp9X+eqUcXr3TMu9tFD7Jtn0LH03V02wC/wDVMu6qvFy91TX31/ZrrfVx2PyKv0LP
UVen63fV+6pl9eS40XNDqLvRuFdrnCW4+Lc6r0srN/M+wY7rc31q7qfs/rU2sWhhZ+Ln1G3Gc4hj
tljLGPqsY4AO2XY+Q2q+l+x7LW+rX/M2V3fzVjFR+sP6KvAzW624mfjemD9E/aX/ALIu3/ne3G6j
e+v/AIf0v8H+ifrJJJJJJJJLJ+tn/iV6z/4Qyv8AzzYtZf/X7/o3/KPXf/D7P/bHpq1kkkkkkklk
1/ovrVkepp9swKPs/fd9luyvtnH0PR/aeD9P+c9f9F/N3ene6iHO6fktZjNzXGmwNw3lrW3Ha6MZ
7rQ6prL/AOa/Sexcl1XdkdLzcLptWfn1PxMvZTnY2QH47zjZFdd+Dm9Rx68rJtyLbfsb8Sy/Myv1
39V+zYeLfRbq3dRrwPrVmuupyLKn4GEPUx6X5G1wu6ntY+nEbdk/pG79tnoeh+i/S212Po9a10ht
/T8OijIos9XNy8q0tYA8UjIsy+qV/a3sca2bKy3GsfW+6r7Y9lVVltf6VYXXKX9Rwup4mYzqJ6te
3Jx8KigZrMTa71aumNdbibelWMyKjRfl2511uy2+6nKfRj0/Zca7mZNGRmWu6oOpsx/Y7pzMKvPr
BpfXVZZdk/spjbW5bsp19D8bOd6mPVjU7MWj1rbsqrhi2jpvTMDq9efRiYmBj1NZhMy95y6t+Nnt
yLektdk+ljNpo+ye+vCzPtNuRV9u9Oi3F0vqu442I3p5x8lu67NvZbcyyBW/J+1Ywvvyv0zsjIxe
oU2/pN92+rMqyfTy8XIqSwsw9HZdgZGNk3ZD8nKvo+z0WW12Nyci7MoDctjPsmO/9Y+z2/br8T0b
q32Wfqfo5Vqwsw9HZdgZGNk3ZD8nKvo+z0WW12Nyci7MoDctjPsmO/8AWPs9v26/E9G6t9ln6n6O
VbH6udMyum5Qxshs/Z+kdNxTc0H03WUHqDL21WOazfs31u/f2W1oPTsTKZ0r6n1vpsa/F9L7S0tI
NUdOzKHeu2P0W257Kf0n+F/RrplznT+n5edldT6hj9SycGjKzbGsppbjHXFZV0m6yz7XiZb978jp
93p7Ltn2f0P5u71Vd/Y3Uf8Ay9z/APMwf/kal+xuo/8Al7n/AOZg/wDyNS/Y3Uf/AC9z/wDMwf8A
5GpfsbqP/l7n/wCZg/8AyNS/Y3Uf/L3P/wAzB/8Akal+xuo/+Xuf/mYP/wAjUv2N1H/y9z/8zB/+
RqX7G6j/AOXuf/mYP/yNS/Y3Uf8Ay9z/APMwf/kal+xuo/8Al7n/AOZg/wDyNS/Y3Uf/AC9z/wDM
wf8A5GrzX/GN9UfrL1L6z4tWCzL6vuxGj7VaypjGlr8h7qHZOPThYVe1vv8A036X9L/xS3fqV9Q/
rb0mqp+Z127Cq2uB6bj7b2sa8C32uzBfhUZDcn+d9HDv/P8ATyf06636p/8AiV6N/wCEMX/zzWqX
UbWY/Uci1rc3p+Xuaa78XHyMzHyWCuuLM3FxaL8Vr/Wb9kt9+N1b7Nh1elm0Y11Sz7a8rG6RnW2d
PdiOd1XpNlWBXsgbR0Ov7Ni2H0MWxlV1VmIy3fXj76v8GtvGsPUutUdRoqurxcTGyMdzsiqzHc6z
Isw7WtqoymU3uZSzC/S2uq9H9NT6D7v1n7OHquVbYzoPU2YeS6tuT9ovoFRN9NdmFmsc7IoadzX0
OvY22pnqXep+gx2X5HpU2Uupsysw5XV8XEyLarLOk10Y5rNV9n2POdl5NjcbK9B9NWzK2Nfl/Zv5
i+5+zD9HJuXXm3dZxc/LwcfINVPSOoYjW20W02W3ZIx31VY2LkV1ZNmxuH73+l6e++mvH9ez7T9n
0HXv6t1Dpxpx8ij9nZD8jL+01OqDScfKwm49Vjx6WZb6uXu9TCsycP0qLf1r9JifaS9Xbf1DDvox
6LPVwsvFtDXgMFwx7MTqln2R73Ct++sOxq32Ppq+2MfVbZVX+lQs7JHX+ldR6Zg1ZFb8nEuqF+Vj
3Y1bX2sNNLXfbKqbrN+9z/1am/0mVfpvT34/rQzcw9YZTgY+Nk05DMnFvv8AtFFlVdbcbIpzLw7L
ez7JkP8A1f7PV9hvy/WusZZX+p+tlVV+nYmUzpX1PrfTY1+L6X2lpaQao6dmUO9dsfottz2U/pP8
L+jWn0mm2vP60+xjmNuzWPqc4EBzRh4FW+sn6bPVrsr/AK9ah9Zf+Tqf/D/Tv/b7DWskkkkkkkks
n62f+JXrP/hDK/8APNi1l//Q7/o3/KPXf/D7P/bHpq1kkkkkkklk9R/Qdd6RlfS9b7TgbOI9WtvU
vX3fyP2N6Ppf92fU9T9D6duskoCmoWuuDGi17WsfYANxawvdWxz/AKTmVutt2f8AGWKaSSSSSSSS
Syfqr7/q/hZJ+nnV/brR2FmY53UMhlf/AATLsmxtO73+l/hLPprWSSSSSSSSSSSSWT9VvZ0LFxef
sHqYG/8Af+xWWdN9fb+Z6/2X1vS/wXqen6ln84tZQtpquaGWsbY0Oa8NcA4bmOFtT4d+fXaxllf7
j1NJJJJJJJJJZPXv0tnSsJ2lWXn1+oR9IfZmX9Xp2fm+7J6dQyz/AID1f8J+lZrJJJJJJJJLJ+tn
/iV6z/4Qyv8AzzYtZf/R7/o3/KPXf/D7P/bHpq1kkkkkkklk/Wb9H0l+cND0yyvOLh9MV47235rK
Hf6XIwG5WJ9JjLftHoXWejbYtZJJJJJJJJJJJZn1kutr6JlMoe6rJyWtxMa1pLSy/Kc3Bxbt7ffW
yrIyKrLLK/0lbP5ve9aFNNVFTKaWNqqqaGV1sAa1rWjaxjGN9rWNappJJJJJJJJJJJLJp/VPrJfQ
NKuqY4y2NGv6bGNeFm22F3ub6uNf0muljP0f6rf/ADVn9I1kkkkkkkkkkklk4v639YM3JOrOm1sw
aQdC2y1tfUM97dv06r6bOkNb6nvZbi37K6vp5Gskkkkkkkksn62f+JXrP/hDK/8APNi1l//S7/o3
/KPXf/D7P/bHpq1kkkkkkkkHKy8XCodk5l1eNj1xvutcGMbJDG7rLC1jdz3bVhfU3rPTszCOFg2O
sxcVzm9NtfXZULsRmwV/Z/tDK3XM6a639l32b7rd+NXkZP8ATK10aSSSSSSSSSSyW/5S6yy1vuwe
lb/TePovzHizFu2O9rv8nY3r49n87j239Qtq9mX0xaySSSSSSSSSSSSSzOvU2/Z6c+hjrr+l3DLZ
SwFzrGhluNl011t91uQ/Bycr7HXur/Xfs3qfofUWhTdVfUy6l7barWh9djCHNc1w3Mex7fa5jmqa
SSSSSSSSSr9QzasDCuzLQ57aWyK2QXvcfbVj0McW+pkZFpZTj1f4W6yutB6NhW4PTq6by12S91l+
SWSWevkWPzMoUbg1/wBnbkX2/Z/U/Sej6fqe9Xkkkkkkkklk/Wz/AMSvWf8Awhlf+ebFrL//0+/6
N/yj13/w+z/2x6atZJJJJJJQuFpqeKXNZaWkVve0vaHR7HPra+p1jGu/M9Wv/jF4P9frvrdldcfg
dSyLM/HdkOr6eMZjm41j2uLfTxKGyy3Lxn5H2O/35OVTd+qWZFq9bx/q5+xeh4FHSh6uZ0atzqWz
sGS57XHMxbXWPd6NXULnev8Az3oYuYzDyNl1WH6C2sXKozKG5GO7fU+YMFpBaSyyuyt4bZVbVY11
d1NjfVpt/RW/pEZJJJJJJJJUc3NtbaMHBDbM6xu/3ya6ayS37VlbS12zc17cbGa9l2bcz06/Ropz
MzEN0/CqwMKnDqLntpbBsfBe9x91uRe9ob6mRkWl92Rb/hbrLLFYSSSSSSSSSSSSSSWTi/5Ge3Bt
/wCTrbCMK/tU6xxdX024fQqqa9/odKsZso9L0emfosmvE/aOskkkkkkkkoXXVUVPuue2qqppfZY8
hrWtaNz3ve72tY1qzG/5avoyG/8AJeLYLqHcjKsaHCq7afZ+z8d7vtGLZ9PLzKsfNxvSxcbHv6hr
JJJJJJJJJLJ+tn/iV6z/AOEMr/zzYtZf/9Tv+jf8o9d/8Ps/9semrWSSSSSSWfnZV9mUzpeE708i
2s235IAd6FIIrDgxwez7XkvL2YP2hv2f9Bl5H6x9i+x5JW9K6a2ijHONXZVi2C6gWj1C24Fz/tXq
Xb7PtfqPssflOd9ofbZZb6nqPVtZ+V017b3dQ6c70s4wbK3PcKLwAGbMqlu+tlr62V1s6hXT9so9
HH/pOJV9hvsYWbVm1F7A6uyt3p30WQLKrAA51NzWlzd+1zHtcx76bqX15GPZdj3VWvsJJJJJJKjm
5trbRg4IbZnWN3++TXTWSW/asraWu2bmvbjYzXsuzbmenX6NFOZmYhsLCqwqixhdZZY71L77INlt
hAa665zQ1u/a1jGtYxlNNLK8fHrpx6aqmWEkkkkkkkkkkkkkklC6mq+p9NzG21WtLLK3gOa5rhte
x7He1zHNWZ9pv6P+jyxZf0xurM8uDnY7P3OpGx/rW1Ve30+oMbd+g/SdV9L7Ld1LL1kkkkkklC66
qip91z21VVNL7LHkNa1rRue973e1rGtWZtv617ciizF6X+dRcA2zKB1b61Qc5+P0/Z/OYuR6WZlv
/Vs3HxsWq/H6gqP8j5QxXezpN+xmEeW0XOLmOwXO/wADiXfoP2Yz+brv9bA9Wn/JWEtZJJJJJJJJ
JZP1s/8AEr1n/wAIZX/nmxay/9Xv+jf8o9d/8Ps/9semrWSSSSSVHqmbbj1ehhhtnUslrhh0ukt3
Af0jJ2lrmYWM59bsq3+pRT6mXkYtFxsLCqwqixhdZZY71L77INlthAa665zQ1u/a1jGtYxlNNLK8
fHrpx6aqmWEklRzej4WZaMkh1GaxuyvNoPp3taCXsrNjf5/Hba71fseU2/Cts/n8a1V/2h1XA06p
jfaqR/2twGPfH/H9LnIzavc5lVX2Ozqm/wDSZGR9iqVjC650XqFppwOoY2Xa1u91dF1djg0ENLyy
p7nbNzmq8kksy76ydErtfQzKbk5NTi23GxGuyr2Fp2v9bFwW5GRUyt/6OyyyrZXZ+j+m9Q29Z6l7
bWfsrBdo+veH5j2/nM9bFs+zdO9zf5zHv6hfbj2/oremZbFewun4WBUasOltLXu32Eaue8gNffkW
um3IyLNv6XIufZdb/hLFYSSSSSSSSSSSSSSSSSSWT+yL8D3dCsrxqRqemPYPshPL/Q9ENu6fbdtb
+kq9fDr/AE2T+zMjKustS/5w4uL7OtN/ZNo035DgMZ5/7rdQ0xn73Cz0ce/7N1H0a/XtwKa1p03V
X1Mupe22q1ofXYwhzXNcNzHse32uY5qmkq+b1Hp/T6hdn5NOJU52xtl9ja2lxBcGB9rmt37WuVH9
u/bPb0Oj9pf92t/pYY/9D9l32n6Nlf8Ak2jP9HIZ6OZ9lU6eitttZl9We3qGXW4Pq9rmY9TmGabM
XAstyKqsiv6X2yx92b+ku2ZNeN6eNVpqF1NV9T6bmNtqtaWWVvAc1zXDa9j2O9rmOas/Cutwso9M
zHudW93+TL7CXGysMD34t17vdZm4zm3ub6v6bJwPTv8AWzMijqV1Wmkkkkkkkksn62f+JXrP/hDK
/wDPNi1l/9bv+jf8o9d/8Ps/9semrWSSSSVfNzasKoPeHWWWO9OiiuDZbYQXNppa4tbv2te9znvZ
TTSyzIyLKcem21gem4VtDr8vLLXZuY5rrtkuZW1jdlOHj2PDbXY9Hvs92z1cq/Ly/QxvtX2eu8kk
kkkq+b07p/UKhTn41OXU129td9bbGhwBaHhlrXN37XOVH/mv0VmmNTZgs71YN9+HWT/pH4/T7sal
9v5vrOr9XZ6f+jYl+wbHfo7eq59mJwMb1GM9o/m2fbseinq36P2/pP2h693/AGqtv32+ov8Amr9X
365OFXnP7W527MsA/wBGzI6g7JuZV+d6LbPS3+p/pHrTppqoqZTSxtVVTQyutgDWta0bWMYxvtax
rVNJJJJJJJJJJJJJJJJJJJJJJZl31Z+r11r739Nxhk2OL3ZLKmMv3uO43syqmsyK8jf+k+0V2+sy
z9J6m9Q/5vV1e7Cz8/EtOhs+0vyZb+56PV/2jjN93+EZR6//AAvp+rvX/N3Gs9+VmZ+Rcfp2/bL6
N37v6v02zCwq9rfb+hxav37P0vqWKxhdD6L0+03YHT8bEtc3Y6yimutxaSHFhfUxrtm5rVeSSSQc
rFozKHY+Q3fU+JElpBaQ+uyuxhbZVbVY1tlN1bvVpt/S1fpFz/U/rfi/VjAd/wA4XWPya7Cyj0mA
vyqy53o30/zOP6tePt/aX9GZRlfQpZj5XTvtPR03VX1Mupe22q1ofXYwhzXNcNzHse32uY5qmkkk
kkksn62f+JXrP/hDK/8APNi1l//X7/o3/KPXf/D7P/bHpq1kkklC66qip91z21VVNL7LHkNa1rRu
e973e1rGtWf0+m3OdT1bOY6txbvwsN4LTjte2N97Hf8AenZU/Zkf9w2epg43/azK6hppJJJJJJJJ
JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJLzf6+/4suqdbzbesdPz3ZOSWx9jyiGgNb6j204V1bW
VVs/m66qLq/p+rkZGbvetP8AxZ9Q6lVgW/VnrdVmN1PpX8yy7R1mKXOrrspc97/tFWPcyzH9ahv2
RlH2Oupdqkkkkkksn62f+JXrP/hDK/8APNi1l//Q7/o3/KPXf/D7P/bHpqz+ifV7oGbi5GTmdMxM
nIsz+ob7raK3vdGblsbussY57trG7VHrn1f6Dh1VOx+mdKxw9xaXWdP+12OdG5lGN0/CFF973M9a
+2xlv6CnH/o9lXq342VRjdLyWU4+N0TpTsp3UT0+y+/pxxmlv2J/VftI6fkN+10vp9jPs9t3656X
9IxftTLca1j/AFcqzMvOxqum9Dob0+6ug3O6cLTa52Ni5dp+ztyMf7MxluS/0/1nJ9Rj/S/R/Z/W
y1idM6L1irFHTejdKw7bcLG6he/Iw68hrW5Ys9DGqrpOE6x+7Hv9XIfbV6eyn9Xu+0fqkXdG6Bbn
dOxbekYDMjG6m/EzTVjVtqt/yflZ9bmsLXP9J7LcW70LfU+z5LPT9XI9CvKtr5nRen5XTcHqtPSu
lVdPz8np7q6G4jWZDKL8rF2Otym76b330v8ATycP7NRXX9ptr+2ZX2f9dln9K6Bb123Dx+m9MxKs
Ct73XZGNX6LXVV49+dkZVdXoOyqq8bqvT6sSp+Ti0V2WdRzMn1LMLp3qG6F0HpXUM2vIyuh4GMW4
m7PxRjsLK7L7PtHTMX9LUPT6hhYHq/tX9HjP/XML2W0/Zvs1freL0fpbsy/9l9Ksrwmvtdh09Ity
DtY31mUZHV8eMPCyMij07nfaMT9RZkV7/tVH6xkFz+mdPpZ17Kp6N0duL0Rthra/Da+y1zcKnPY1
+00soZVff9P9N9pp/Q+niej9ovtj6vdPxM7CZn9J6PZV1G51DaaMFrXUuFORnAnLtdY3MYxuI7H/
AKFher6n2j9D/R1X/ZfSv2V/zk/ZHSP2T9n+2/YvsLPtP2bZ6+77b6n2f7X9n/T/AGf7F6PrfqP2
v/vRSb0boFWd1HFq6RgPyMnqbMTCNuNW6qr/ACfi59jnMDWv9JjKsq70KvT+0ZL/AE/Vx/Xsyqi9
K+q/Sv2/1DG6j0vplvpYmG6s0YrGVnfZ1Hfb9ltF/wBmtd6bKbP1jI9VmPVb6n/aeix1z6v9Bw6q
nY/TOlY4e4tLrOn/AGuxzo3Moxun4Qovve5nrX22Mt/QU4/9Hsq9W/Gz8bC6JkdMy7f2V0qm3CyR
jWZV/THVBwdVRk1uq6Na1ue/Itsy6cGjE+1b8h/61R6nqU4VgsfF6PY3Mod0vpTLMRuPacy/pFuM
A3IdkUsoq6RkfrmdkOvxGU0ejl1faH5n6H9Pi/Z8u70Dpn1fzsrLwsno+BY/FrpuF37LdgyLzkV+
l9j6g2279H9j3/aW2+lb63pen+rv9Sxl/V7ot3UH9N6b0npVFtFNeRffkYNdzdtzrqaKqqKXYjnP
c7Evfba+/wDQ/of0OR9o/VYXfV/pTX4vTG9H6QzqeRXda7IOGx9Da8d1NT7W436G51uR9qxtuL9p
2Y3qX/ruT9lr+20snpnT8fOx+jDo3R7OoW3VtfknDayg0XU9RvrubjzbczIx7ulW78b7RZXk1+n+
t4v2v9Qhf0vFx8bqmQ/pHRXM6DuOSRggHK20VdSdXRX6h/Zm2m9mP61lvVPVt/T+hT6fo29L/wA0
/qr/AOU2B/7C0/8ApNVaek9K6b9asL9nYePh+rgZvqfZ6mVbtt3TNm/0ms37N79q6BJJJJJJJJcz
0T6vdAzcXIyczpmJk5Fmf1DfdbRW97ozctjd1ljHPdtY3asjrvRen5HQer9Q6d0rpVGLjU5tLWOx
GtyC7G9fFvy6syr2Yr6r6bbMan7Lket6NX61i/av1LQo6B0/J6l1KqnovRxi9Ou9Gtj8Vosuc7Fx
8tjH3NY5mGyu/J/n/s+b61P6P7NT6Hq5NHBxOhO6nh4tvTemZ1OdY+pltPR7MWv203ZjcmnPynZe
Fm1WNxdlbMd/6Zl32qq70qf0k3dM6e7Bw+s09G6Oen9Quw214z8Novroy7qKGXPyGl1N+R6N/wDR
vs9FePZb/S8v7J+u3bPq70rNzMrH6Z0vpGKzAsbRe/JwGXl9jq6sv9FXTbhelVVTk0/pH2Wvut9X
9FR9n9TKpYnTOn9WzrsXA6N0fDbjUsdfZfhtyCL25HUOnZNNTKjg+tjut6b6lGS99Fmz+cxP1n9T
r5+J0CzCxMb9iYDcjJyL8bIdVj10h7cfKZ0P9Bd6d12F9s6jl4LrNn2i/D6dZm/Zr/t1GLZZNvRe
n5Oa3Cd0rpTrKs2qrGycbEbW21tH6frl9+O77Sz7FVj2/sZn6TL9Lrf879lv+z/ZNfqP1f6A3Kx+
m4PR+mV5eTXbeL78OuytldBoZb+hr9Cy619mXRXXX61DNnq3+r+h+zZOLT0bFqy78T9kdIsy8jq4
w9z8YGmusdMrzvXoq2+pX+kp+1fYfU2epbdi/bPf+0Vb6l0bpmJe2j7D0hrxWwuZT0W7Oe6RDsm2
vAe39n1XXNvrxqLvtG/7PZ+uXfpqseWJ0zovWKsUdN6N0rDttwsbqF78jDryGtbliz0Maquk4TrH
7se/1ch9tXp7Kf1e77R+qRw+m9KzqaMVvQ+kY/U8izO3POIy6iqvByfsD9rNuLdlW2epjMb78Nn8
/lfo/SrwrlmdN6Vg034ruh9IyOp49mDteMRlNFtedk/YGbmbcq7Ftr9PJY735jP5jK/SerZhU2sX
6u9Ko6rV07qPS+kZP2nHuyK7MfAZj7Ps78ap7HsttzvW9b7cza7fT6Xo/wCF9X9ELqv1X6V+3+n4
3Tul9Mq9XEzHWG/FY+sbLOnbLfstQo+02t9R9Nf6xj+kzItt9T/tPfX6n0forulXsr6N04dSweo4
OJaWUV1VWuffgXe14quupx8rFzK2ZFey/wBD1L8f9crr9bIh1zofSsLpXU8PM6Z0x+W/pmZl4mXi
YbMfb9nYyuxrq7H5VldtdmVj20X1ZH6T9L+ix/s7H5WhX9X+lYuZi1dT6P0ixnUbHVUNxsNjTTY2
u3M9K227f9tq9HGuZ9qZTgv9Wur9S/Wf1O31ToP1VwMM5A6HgWvdZVRUz7PS0Gy+yvEx/Us9J/p1
etfX61ja7X11f4K3+bVR/wBXeldLxcvO6t0vpGXiYuPZkOOLgMosb6Q9RzG1X25ld/q17/d6+L6L
6/8ADev+rxs+r3T8A1ZXUek9HtxbrqqHY+PgtbZU7JsZjUFuVa57M1lV91Vdv6pgepTvyv0fpfYr
s/C6ZVfg9Hy7OjdD3dcbWyqluGAKHPx7c/7VZeS77Uz0sWz/ACf6GL77fs/7S/Q/a7tfpH1f6BkH
Mxszo/TH5GBkDHfdVh11ss3U4+a17aLPtD6drMz0dv2i7+a9X/CelXS6t07p/T6vrXTgY1OJU7od
b3V0VtraXEdYaXllTWt37WtXZr//0e/6N/yj13/w+z/2x6as/on1h6BhYuRjZnU8TGyK8/qG+m2+
tj2zm5b27q7Hte3cx25LqPXOgX5WPnYP1h6Zj5ePXbQDfbXdWa7jRZb+iry8Oz1fUw6PTs9fZs9X
9E/f+iq4+b0BubXm5X1k6ZbaMv7daK311tdZ9lu6Rsr35mQ6qr7M7Ef7vWf69OR+k9PKrqxNDC69
9VcXJz7/ANuYD/t+Q3I2/aKRs20Y2Fsn1Xb/AOiepu/4RZ+Lm9A6fi4bOm/WTpleXjYlGDfbe+u2
u6vHDvRf9nZmY9lNtdllzq/TytmzItZfXkfq1mOWvP8Aqq27FybPrBgPyqst2dlWevSBbY7Gt6Zs
rr9f9WqqptpbT/PP9LG/T2X5Fl2Uq78roRpx+n1fWjp1XSsK7GtxscPpNuzFtqyasS/LflFtuOxt
PpVOZjU5X9H+0ZOV6eT9sNn5/wBW7cp2Th9c6Ow2XMyrK8w1ZTRkVMbj05mLtzMN+NkNorrqd77P
5qr0fQt+0vyT9G6z9Wum0Gl3XumFh+hjYz8bGxqtXOd9kx67LLmetv8AUv8AtGXk/pvfV6P80qV+
Z0WzFy+mV/WbpTOlZzsg3VudW7IDcx9l+Y2rLGfXQ1+/Ju+zPdgWej+i9WvJ2fpTWZ31bu6d1jEu
+sXTjb1prhZay2pra3PxKOmvcyl2TY5zN2N6+z1v8J6Pqf4ZXc3r31VysnAv/bmAz7BkOyNv2ik7
91GThbJ9Vuz+l+pu/wCDWf8AbegfZf2R/wA5OmfsL0/s/wBl31/aPs8bPsf2/wC2en6Xp/q3q/Yv
tf2T/tT9t/X0WzP+qrrsrJr+sGAzKty252LZ69JFVjcarpmyyv1/1mq2mq5t38y/0sn9BZRkV05S
n03rHQsfqGV1DN+snTsq/LpopLK7Kaa2Ch2S9vot+0ZFuyz7X7vWuuf63qfpfRsqx8eF3V+jn7Dk
1fWbph6nh47sa3JvdU+u0W/Z35Nv2WjLxPStsuwqbK9mR6VTPVr9Kz9G+quMzou92WfrN0o5xyW5
zLA6sUi8Y7+k2bsf7f6rsd3T/S2Vfa/UrzPUyfXsos+x1Rsy+lXZ7OqW/WjpH2+rZ6ZbsFP6JuVT
TvoPUX2u/RdV6l6v60z1LPsP819lvrzrFfVumC3My7PrR0oZuXjDGbdSamNrNRtfhXspvzsre+m3
My3Xssfsyf1b+j+hd9qPmdc6A7KOd036w9MxsuyttF5vtrvrfXWbLKf0TMvEsZbTZfd6dld+zZfb
69V36t9mjb1joT24+Sz6ydO/auM2xgyn2Uuqcy9zLMjHdh15FLvs+6mj7P8ArX2qr7NR6uXk/rf2
sTM76tvzsbqeZ9YunW51NwstfXbVXW6tlObiUY1NLsm51LK3dTvyXW23ZN1l3qf4D7PViyys/wCq
uRh9bxf+cGA39t7/AH+vSfS34tHTfo+v+m2/ZvW/wX0/T/4Rav8Azs+qv/lzgf8AsVT/AOlFVp6t
0rqX1qwv2dmY+Z6WBm+p9ntZbt3XdM2b/Sc/Zv2P2roEkkkkkkklzPRPrD0DCxcjGzOp4mNkV5/U
N9Nt9bHtnNy3t3V2Pa9u5jtypdRyuhZOFm9Mw/rR07D6f1Bt/qsL6bbWPyfUsyPQyH5TGfZ7r7X2
20249136bIrxsrF/VfsduzqH1Quo6xjXdewjV1pzjZsyaWura/Go6c9rHOssa5+3G9Xfs/wn82hH
rHT78rFvzvrP0ewYV3r0tpDapcWWYtosdZ1LJ3MdiZOS2vbs9PI9C/8ASVU2Y1+Y3qnRcu7HxD1O
vAw8XIoyBS7PwXYVZxra8n08AY1v7TyarX1eli4/UPs+Hi41vrsxce3CwcFbF/Wui15V2T0r6x9K
xjluFmVXkPryGusaxmOy6r0s3CfS91FNVVrd9tP6Gn0q6bftD8ldM6h9UOm5d+RV17CsGRTXW8Py
adxsbdm5uRkve2xrN+Vf1Kx/pVU001f4H9F+iqruyfqqMYtq6/0w5IszSH32U20upz73ZmVhZOJ9
pr9ar+Z97L6bPUx6/wDtPZkYl0+l9R+r+FlfaH9f6PWNrWOqwG42K21tbPRoZmOtyc++xmIzb9j+
z3Yno/Q/TVexlrqHXfq3fbVmYfXunY+djtfXVbZdVbWa7TW6+m6huRQ57Huoota6q+i6u6iv9J6H
2jHvpYuX9XaspuXk/WbAyLvt56hYfVoYCThHpH2etrbzsqZPq07/AFbfS/QXevb+tvLZ1npVOZlZ
HTPrL0ihmbY2+9mSWXn1G11Yn6KynqGDsq9HFp/Rvrsf6vq/pf8AB1Z9vWOhdNoxMbB6pXYcXHbi
15vT8vp7bnU1FzaMbPx+r3fZbfSq9F1WTV6ln2j7d6VXTab/AEcqxg5f1ew8HG+z/WDp1PUsd2S5
ltmSzJrDMy45uTiXerkUZGYxj/R25frY2Vbdi13v/R25OJaZ+d9W8hj7cz6xdOszrbsSy2+u2plf
p4OQ3OoxqcZ2Ta6tjnevuttyL7vWybLP5hmPi03bOvfVWzquP1H9uYA+z49+P6f2in3eu/Ft37/V
9vp/Yvo7P8KqV/VOkvt6fmV/WrpwzsHGsx7bbHUOrvdccV11t1FeTQ6pm7D9VtWPfV+mfX+m9Cqz
HyFkZn1Yv6dbjn6x4VeZlZNGbk5rL6JNtFmNa00Y9lttNTG04NONjts+0emxldmT9tu9ay+GVm9A
6hi5jOpfWTplmXk4l+DRbQ+uqumvIDfWf9nfmZFl1tlldLrPUytmzHqZRXj/AKzZkWKOsdCdlU3d
S+snTsxuE4vww2ymlwe5j8f7RmPbkWMyMj7PbbX+r04WL+nvs+yf0X7KXJ639WMyrJoyvrBhOrtu
ruxdmRQ11BqFFlGx297b31Z2P9t/T1vZ+k+z21WUITetdFyqsjH6z9Y+lZeLkUvodj4768drm2jZ
abXvzcy/fs9lXoXY2z1LvU9b9D6EB1fo9766+pfWbpmVhUWMtZWx1VVz30ubdiuy8huXZVZ6dtde
RZ9kxMH1citn83ierh2rFz/qrj4fRMX/AJwYDv2Js9/r0j1dmLf036Pr/od32n1v8L9D0/8AhFbw
uvfVXFyc+/8AbmA/7fkNyNv2ikbNtGNhbJ9V2/8Aonqbv+EWZ1bqPT+oVfWu7AyacupvQ62Ososb
Y0OA6w4sL6nObv2uauzX/9Lv+jf8o9d/8Ps/9semrWSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSWT9bP/Er1n/whlf+ebFrL//T7/o3/KPXf/D7P/bHpq1kkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkklk/Wz/xK9Z/8IZX/nmxay//1O/6
N/yj13/w+z/2x6atZJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJZ
P1s/8SvWf/CGV/55sWsv/9XtcZ3WKuqdY/Z1GJl1WZbHWG3JtofW/wCyYLPRdW3Ayq3/AKNld3qV
3/4b/SK19p+tX/ldgf8Asdd/8ikvtP1q/wDK7A/9jrv/AJFJfafrV/5XYH/sdd/8ikvtP1q/8rsD
/wBjrv8A5FJfafrV/wCV2B/7HXf/ACKS+0/Wr/yuwP8A2Ou/+RSX2n61f+V2B/7HXf8AyKS+0/Wr
/wArsD/2Ou/+RSX2n61f+V2B/wCx13/yKS+0/Wr/AMrsD/2Ou/8AkUl9p+tX/ldgf+x13/yKS+0/
Wr/yuwP/AGOu/wDkUl9p+tX/AJXYH/sdd/8AIpL7T9av/K7A/wDY67/5FJfafrV/5XYH/sdd/wDI
pL7T9av/ACuwP/Y67/5FJfafrV/5XYH/ALHXf/IpL7T9av8AyuwP/Y67/wCRSX2n61f+V2B/7HXf
/IpL7T9av/K7A/8AY67/AORSX2n61f8Aldgf+x13/wAikvtP1q/8rsD/ANjrv/kUl9p+tX/ldgf+
x13/AMikvtP1q/8AK7A/9jrv/kUl9p+tX/ldgf8Asdd/8ikvtP1q/wDK7A/9jrv/AJFJfafrV/5X
YH/sdd/8ikvtP1q/8rsD/wBjrv8A5FJfafrV/wCV2B/7HXf/ACKS+0/Wr/yuwP8A2Ou/+RSX2n61
f+V2B/7HXf8AyKS+0/Wr/wArsD/2Ou/+RSX2n61f+V2B/wCx13/yKS+0/Wr/AMrsD/2Ou/8AkUl9
p+tX/ldgf+x13/yKS+0/Wr/yuwP/AGOu/wDkUl9p+tX/AJXYH/sdd/8AIpL7T9av/K7A/wDY67/5
FJfafrV/5XYH/sdd/wDIpL7T9av/ACuwP/Y67/5FJfafrV/5XYH/ALHXf/IpL7T9av8AyuwP/Y67
/wCRSX2n61f+V2B/7HXf/IpL7T9av/K7A/8AY67/AORSX2n61f8Aldgf+x13/wAikvtP1q/8rsD/
ANjrv/kUl9p+tX/ldgf+x13/AMikvtP1q/8AK7A/9jrv/kUl9p+tX/ldgf8Asdd/8ikvtP1q/wDK
7A/9jrv/AJFJfafrV/5XYH/sdd/8ikvtP1q/8rsD/wBjrv8A5FJfafrV/wCV2B/7HXf/ACKS+0/W
r/yuwP8A2Ou/+RSX2n61f+V2B/7HXf8AyKS+0/Wr/wArsD/2Ou/+RSX2n61f+V2B/wCx13/yKS+0
/Wr/AMrsD/2Ou/8AkUl9p+tX/ldgf+x13/yKWf8AWG36xW9A6nVk4mBjY9mJe27I+2Xv9Nhre2y7
0mdL32+kz3+m36a6Zf/Z

------=_NextPart_000_0000_01C07CCD.A19B8E00--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 10:31:16 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10653
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 10:31:14 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8895244369; Fri, 12 Jan 2001 09:29:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 40E4C44351
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 09:28:31 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0CFSMJ25575;
	Fri, 12 Jan 2001 09:28:22 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] SDP in a REFER
Message-ID: <20010112092822.A16032@fdd.com>
References: <B65B4F8437968F488A01A940B21982BF9AB05E@DYN-EXCH-001.dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <B65B4F8437968F488A01A940B21982BF9AB05E@DYN-EXCH-001.dynamicsoft.com>; from jdrosen@dynamicsoft.com on Thu, Jan 11, 2001 at 06:07:09PM -0500
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 09:28:22 -0600


Okay.  We will do our best.  Sorry for the trouble.

--
Rick
Rick_Dean@3com.com

On Thu, Jan 11, 2001 at 06:07:09PM -0500, Jonathan Rosenberg wrote:
> To be honest, I am beginning to get annoyed here.
> 
> There is clearly not consensus. I still don't know what the problem is, and
> I appear to not be alone. Instead of rambling on about SDP in REFERs and
> insisting on some deep insight granted through the construction of phones, I
> would strongly suggest you take a step back, and write an email or I-D that
> clearly states the problem, with pictures and call flows, and clearly
> explains why the proposed REFER mechanism that we have been discussing for
> months and months (if not a year now) is suddenly quite wrong.
> 
> The discussions will go nowhere until we are on the same page about the
> scenarios and problems to be solved.
> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>  
> 
> > -----Original Message-----
> > From: Rick Dean [mailto:siplist@fdd.com]
> > Sent: Thursday, January 11, 2001 4:49 PM
> > To: sip@lists.bell-labs.com
> > Subject: [SIP] SDP in a REFER
> > 
> > 
> > 
> > Hey!
> > 
> > I wanted to check on consensus for including SDP
> > in a REFER request in an connected* call-leg.
> > This helps to reduce the number of messages and 
> > the delay of processing.  It also makes some
> > implementations easier.  Fewer packet loss
> > conditions,.... blah blah blah.
> > 
> > *(i.e. a call-leg where an INVITE has already 
> > succeeded, but a BYE has not. Is there a better 
> > name?  I would call to-from tags assigned as
> > "bound" maybe "established"?  We need a linguist.) 
> > 
> > --
> > Rick
> > Rick_Dean@3com.com
> > 
> > 
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> > 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 10:42:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10874
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 10:42:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0239F4435F; Fri, 12 Jan 2001 09:43:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from topaz.3com.com (topaz.3com.com [192.156.136.158])
	by lists.bell-labs.com (Postfix) with ESMTP id 4FB6244352
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 09:42:21 -0500 (EST)
Received: from opal.3com.com (opal.3com.com [139.87.50.117])
	by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id f0CFf0117919;
	Fri, 12 Jan 2001 07:41:00 -0800 (PST)
Received: from hqoutbound.ops.3com.com (pc-48-104.corp.3com.com [139.87.48.104] (may be forged))
	by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id f0CFg4c09164;
	Fri, 12 Jan 2001 07:42:04 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 882569D2.00566988 ; Fri, 12 Jan 2001 07:43:51 -0800
X-Lotus-FromDomain: 3COM
From: Jacek_Grabiec@3com.com
To: Juha Heinanen <jh@lohi.eng.telia.fi>
Cc: sip@lists.bell-labs.com
Message-ID: <882569D2.00566673.00@hqoutbound.ops.3com.com>
Subject: Re: [SIP] why is contact header mandatory invites and positive
	 responses?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 09:43:21 -0600



Juha wrote
>to me it doesn't make sense that contact header is mandatory in invites
>and positive responses.

>in cases where the company policy is that sip messages must go via a
>given proxy (that then relays them to/from uas within the company
>network), the contact header gives wrong information to the other party.
>the semantics of contact header "it provides a URL where the user can be
>reached for further communications" simply are not true in such a
>situation.

The inclusion of Contact header makes a lot of things easier, ranging from such
simple facts that it allows
UA to present to the user who was contacted in case an INVITE was forked
(otherwise the only difference
in 200OK is different To-tag which doesn't say much about who was contacted) to
making Record-Route following
easier. If you have UAS that doesn't follow Record-Route properly then you have
two options: do not call such a UAS :-)
or make your contact to be myua@proxy-to-go-through.com instead of IP address of
your phone.

>i would not care otherwise, but i have already met three commercial sip
>user agents that inspite of the record route in the messages, still send
>their acks to the address in the contact header instead of that in the
>record-route.

obviously these are not SIP compliant implementations and I don't think there is
a way to deal with it. There is
no way to make everything work as they should if one party follows its own
secret logic.

>unless the contact header can't be made optional also in invites and
>positive oks, i would very strongly urge that the sip bakeoffs and call
>flow documents would include test cases to check the correct ua behavior
>in the presense of both record-route and contact header.

>-- juha
regards, Jacek Grabiec



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 11:25:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11717
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 11:25:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EF2074435B; Fri, 12 Jan 2001 10:26:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104])
	by lists.bell-labs.com (Postfix) with ESMTP id D0AD84435B
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 10:25:29 -0500 (EST)
Received: by zcamail04.zca.compaq.com (Postfix, from userid 12345)
	id A1FBD269; Fri, 12 Jan 2001 08:26:10 -0800 (PST)
Received: from excmun-gh02.eur.compaq.com (excmun-gh02.dem.cpqcorp.net [16.41.92.161])
	by zcamail04.zca.compaq.com (Postfix) with ESMTP
	id BF4F3362; Fri, 12 Jan 2001 08:26:09 -0800 (PST)
Received: by excmun-gh02.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21)
	id <CQ4SRQLC>; Fri, 12 Jan 2001 17:25:15 +0100
Message-ID: <C1434589DE6ED411885900508BDF604D0A0388@vbeexc01.vbe.cpqcorp.net>
From: "Rolland, Frederic" <Frederic.Rolland@Compaq.com>
To: "'???'" <hslee@miptel.com>
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] [SIP]How do the proxy server search the next proxy serv
	er ?
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="KS_C_5601-1987"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 17:25:06 +0100

Hello!
I think there are 3 differents URIs that can be used...
* Since "UAc" wants to contact UAs "dragon" registered at "bbb.com" domain,
requested URI would normally be "sip:dragon@bbb.com"... (no host address,
just domain identifier, then "sip.bbb.com" must locate "dragon" user)
In this case, "sip.aaa.com" proxy has simply to place DNS requests for a
relevant SIP service handler at "bbb.com", that is "sip.bbb.com", to get
the proper address and so the route to it..

* If "UAc" knows current static host address mapping for UAs "dragon", like
"dragon.bbb.com" (host address, this time), or if no location service is
used at "sip.bbb.com" (allowing proxy to locate the user's current host)
"UAc " must use dragon@dragon.bbb.com, but I'm not sure that the session
will go through "sip.bbb.com" this time...

* "sip:dragon@sip.bbb.com" is certainly valid too, it is a bit like for the
first case, but now we already know the SIP server for "bbb.com"...

Hope I'm right and it helps

Frederic.


-----Original Message-----
From: hslee@miptel.com [ mailto:hslee@miptel.com <mailto:hslee@miptel.com> ]
Sent: Friday, January 12, 2001 11:27 AM
To: sip@lists.bell-labs.com
Subject: [SIP] [SIP]How do the proxy server search the next proxy server ?






proxy 1 : sip.aaa.com
proxy 2 : sip.bbb.com
UAc : arnold@arnold.aaa.com
UAs : dragon@dragon.bbb.com


1) When UAc sends a request(INVITE) to proxy 1, what is the Request-URI in
the Request-Line ?
    (a) INVITE : sip:dragon@sip.bbb.com
    (b) INVITE : sip:dragon@dragon.bbb.com
    Which is the correct answer ?

If (b) is right,
2) How do the proxy server 1 search the next proxy server 2?

Please, Could you correct me ?
Happy new year and have a good healthy!!!
  


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 13:52:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15001
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 13:52:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9E65A44337; Fri, 12 Jan 2001 12:53:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 5622644336
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 12:44:16 -0500 (EST)
Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA23682;
	Fri, 12 Jan 2001 10:44:12 -0800 (PST)
Received: from cisco.com (sunithak-lnx.cisco.com [128.107.140.122])
	by mira-sjc5-1.cisco.com (Mirapoint)
	with ESMTP id AHF11547 (AUTH sunithak);
	Fri, 12 Jan 2001 10:44:03 -0800 (PST)
Message-ID: <3A5F5073.658A18AB@cisco.com>
From: Sunitha Kumar <sunithak@cisco.com>
Organization: Cisco Systems
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jacek_Grabiec@3com.com
Cc: Juha Heinanen <jh@lohi.eng.telia.fi>, sip@lists.bell-labs.com
Subject: Re: [SIP] why is contact header mandatory invites and positiveresponses?
References: <882569D2.00566673.00@hqoutbound.ops.3com.com>
Content-Type: multipart/alternative;
 boundary="------------DE64D404300F7159E1A55180"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 10:44:03 -0800


--------------DE64D404300F7159E1A55180
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

If a contact is contained in a response, then that gets appended to the Route list,
as given in 6.34.2 in the Sept4th SIP bis.
If a contact is contained in the initial request, i.e INVITE, then, my
understanding is, the responses should look at via on the INVITE, and get routed to
those addresses. In this case, since the proxies have added their address in the
Via, while forwarding the message, the response goes to the same set of proxies.
When the response reaches the last proxy, then the contact is looked up, and the
response is sent to that UAC.
So, in both cases, the Contact field is handled gracefully.





Jacek_Grabiec@3com.com wrote:

> Juha wrote
> >to me it doesn't make sense that contact header is mandatory in invites
> >and positive responses.
>
> >in cases where the company policy is that sip messages must go via a
> >given proxy (that then relays them to/from uas within the company
> >network), the contact header gives wrong information to the other party.
> >the semantics of contact header "it provides a URL where the user can be
> >reached for further communications" simply are not true in such a
> >situation.
>
> The inclusion of Contact header makes a lot of things easier, ranging from such
> simple facts that it allows
> UA to present to the user who was contacted in case an INVITE was forked
> (otherwise the only difference
> in 200OK is different To-tag which doesn't say much about who was contacted) to
> making Record-Route following
> easier. If you have UAS that doesn't follow Record-Route properly then you have
> two options: do not call such a UAS :-)
> or make your contact to be myua@proxy-to-go-through.com instead of IP address of
> your phone.
>
> >i would not care otherwise, but i have already met three commercial sip
> >user agents that inspite of the record route in the messages, still send
> >their acks to the address in the contact header instead of that in the
> >record-route.
>
> obviously these are not SIP compliant implementations and I don't think there is
> a way to deal with it. There is
> no way to make everything work as they should if one party follows its own
> secret logic.
>
> >unless the contact header can't be made optional also in invites and
> >positive oks, i would very strongly urge that the sip bakeoffs and call
> >flow documents would include test cases to check the correct ua behavior
> >in the presense of both record-route and contact header.
>
> >-- juha
> regards, Jacek Grabiec
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

--
Sunitha Kumar
http://www.cisco.com



--------------DE64D404300F7159E1A55180
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
If a contact is contained in a response, then that gets appended to the
Route list, as given in 6.34.2 in the Sept4th SIP bis.
<br>If a contact is contained in the initial request, i.e INVITE, then,
my understanding is, the responses should look at via on the INVITE, and
get routed to those addresses. In this case, since the proxies have added
their address in the Via, while forwarding the message, the response goes
to the same set of proxies. When the response reaches the last proxy, then
the contact is looked up, and the response is sent to that UAC.
<br>So, in both cases, the Contact field is handled gracefully.
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<p>Jacek_Grabiec@3com.com wrote:
<blockquote TYPE=CITE>Juha wrote
<br>>to me it doesn't make sense that contact header is mandatory in invites
<br>>and positive responses.
<p>>in cases where the company policy is that sip messages must go via
a
<br>>given proxy (that then relays them to/from uas within the company
<br>>network), the contact header gives wrong information to the other
party.
<br>>the semantics of contact header "it provides a URL where the user
can be
<br>>reached for further communications" simply are not true in such a
<br>>situation.
<p>The inclusion of Contact header makes a lot of things easier, ranging
from such
<br>simple facts that it allows
<br>UA to present to the user who was contacted in case an INVITE was forked
<br>(otherwise the only difference
<br>in 200OK is different To-tag which doesn't say much about who was contacted)
to
<br>making Record-Route following
<br>easier. If you have UAS that doesn't follow Record-Route properly then
you have
<br>two options: do not call such a UAS :-)
<br>or make your contact to be myua@proxy-to-go-through.com instead of
IP address of
<br>your phone.
<p>>i would not care otherwise, but i have already met three commercial
sip
<br>>user agents that inspite of the record route in the messages, still
send
<br>>their acks to the address in the contact header instead of that in
the
<br>>record-route.
<p>obviously these are not SIP compliant implementations and I don't think
there is
<br>a way to deal with it. There is
<br>no way to make everything work as they should if one party follows
its own
<br>secret logic.
<p>>unless the contact header can't be made optional also in invites and
<br>>positive oks, i would very strongly urge that the sip bakeoffs and
call
<br>>flow documents would include test cases to check the correct ua behavior
<br>>in the presense of both record-route and contact header.
<p>>-- juha
<br>regards, Jacek Grabiec
<p>_______________________________________________
<br>SIP mailing list
<br>SIP@lists.bell-labs.com
<br><a href="http://lists.bell-labs.com/mailman/listinfo/sip">http://lists.bell-labs.com/mailman/listinfo/sip</a></blockquote>

<pre>--&nbsp;
Sunitha Kumar
<A HREF="http://www.cisco.com">http://www.cisco.com</A></pre>
&nbsp;</html>

--------------DE64D404300F7159E1A55180--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 16:07:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24374
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 16:07:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3288144337; Fri, 12 Jan 2001 15:08:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by lists.bell-labs.com (Postfix) with ESMTP id 415AD44336
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 15:07:56 -0500 (EST)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261)
 id <0G7200D01IOKTY@firewall.mcit.com> for sip@lists.bell-labs.com; Fri,
 12 Jan 2001 21:07:32 +0000 (GMT)
Received: from dgismtp04.wcomnet.com ([166.38.58.144])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0G7200D4PIOJ68@firewall.mcit.com> for sip@lists.bell-labs.com;
 Fri, 12 Jan 2001 21:07:32 +0000 (GMT)
Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262)
 id <0G7200B01IOI74@dgismtp04.wcomnet.com> for sip@lists.bell-labs.com; Fri,
 12 Jan 2001 21:07:31 +0000 (GMT)
Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0G7200A01INCRW@dgismtp04.wcomnet.com> for
 sip@lists.bell-labs.com; Fri, 12 Jan 2001 21:07:30 +0000 (GMT)
Received: from omzexch007.mcit.com ([166.37.194.38])
 by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0G7200A1IINBJG@dgismtp04.wcomnet.com> for
 sip@lists.bell-labs.com; Fri, 12 Jan 2001 21:06:47 +0000 (GMT)
Received: by omzexch007 with Internet Mail Service (5.5.2651.58)
 id <CSGVCRYB>; Fri, 12 Jan 2001 21:06:47 +0000
Content-return: allowed
From: "Pizzimenti, Joe" <Joe.Pizzimenti@wcom.com>
To: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
Message-id: <492EB4A3F68CD411ABE800508B69362E239507@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_JNTHqFBwxrlI4bga2xvEfw)"
Subject: [SIP] Contact in proxy non 407 response
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 21:06:45 +0000

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.

--Boundary_(ID_JNTHqFBwxrlI4bga2xvEfw)
Content-type: text/plain; charset=ISO-8859-1

I recently ran across this question and after looking at the 02 bis, I would
like opinions regarding the following.

Should a 407 proxy response include the Contact header that was in the
original INVITE?

Should the proxy remove the contact header/headers that are in the original
INVITE? or may the proxy return the Contact header(s) found in the original
INVITE?

There have been discussions on the list with the title of why is contact
header mandatory invites and positiveresponses
but nothing about whether a proxy may or may not return the Contacts that
were sent in the request, in the 407 response.

- Joe Pizzimenti




--Boundary_(ID_JNTHqFBwxrlI4bga2xvEfw)
Content-type: text/html; charset=ISO-8859-1
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=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>Contact in proxy non 407 response</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">I recently ran across this question =
and after looking at the 02 bis, I would like opinions regarding the =
following.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Should a 407 proxy response include =
the Contact header that was in the original INVITE?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Should the proxy remove the contact =
header/headers that are in the original INVITE? or may the proxy return =
the Contact header(s) found in the original INVITE?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">There have been discussions on the =
list with the title of<U></U></FONT><U></U><U> <FONT COLOR=3D"#0000FF" =
FACE=3D"Times New Roman">why is contact header mandatory invites and =
positiveresponses</FONT></U>
<BR><FONT SIZE=3D2 FACE=3D"Arial">but nothing about whether a proxy may =
or may not return the Contacts that were sent in the request, in the =
407 response.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">- Joe Pizzimenti</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>

--Boundary_(ID_JNTHqFBwxrlI4bga2xvEfw)--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 16:34:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25150
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 16:34:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 97ABE4433E; Fri, 12 Jan 2001 15:35:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16])
	by lists.bell-labs.com (Postfix) with ESMTP id C0AE144337
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 15:34:17 -0500 (EST)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260)
 id <0G7200601JWMPC@firewall.mcit.com> for sip@lists.bell-labs.com; Fri,
 12 Jan 2001 21:33:58 +0000 (GMT)
Received: from pmismtp03.wcomnet.com ([166.38.62.38])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0G72003K8JWME0@firewall.mcit.com> for sip@lists.bell-labs.com;
 Fri, 12 Jan 2001 21:33:58 +0000 (GMT)
Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258)
 id <0G7200501JWJD9@pmismtp03.wcomnet.com> for sip@lists.bell-labs.com; Fri,
 12 Jan 2001 21:33:57 +0000 (GMT)
Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0G7200501JVN6A@pmismtp03.wcomnet.com> for
 sip@lists.bell-labs.com; Fri, 12 Jan 2001 21:33:54 +0000 (GMT)
Received: from omzexch006.mcit.com ([166.37.194.37])
 by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0G72000PLJU06V@pmismtp03.wcomnet.com> for
 sip@lists.bell-labs.com; Fri, 12 Jan 2001 21:32:24 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2651.58)
 id <CSHL5071>; Fri, 12 Jan 2001 21:32:24 +0000
Content-return: allowed
From: "Ngo, Dai" <c-Dai.Ngo@WCOM.Com>
To: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
Message-id: <492EB4A3F68CD411ABE800508B69362E11C486@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_q/i+Yy016s2Cbd3/MghVTA)"
Subject: [SIP] Request-Contact Header
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 21:32:21 +0000

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.

--Boundary_(ID_q/i+Yy016s2Cbd3/MghVTA)
Content-type: text/plain; charset=iso-8859-1

 

 

I recently ran across this question after looking at the IETF
draft-mahy-sip-message-waiting-00.txt:

Where is the Request-Contact header documented?

Thanks.

-- Dai Ngo 

 




--Boundary_(ID_q/i+Yy016s2Cbd3/MghVTA)
Content-type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Contact in proxy non 407 response</TITLE>

<META content="MSHTML 5.00.3013.2600" name=GENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE>
  <DIV class=OutlookMessageHeader><FONT 
  face="Times New Roman">&nbsp;</DIV></FONT>
  <P><FONT color=#0000ff><FONT face=Arial size=2>I recently ran across this 
  question after looking at the&nbsp;<SPAN class=70452821-12012001>IETF 
  draft-mahy-sip-message-waiting-00.txt:</SPAN></FONT></FONT></P>
  <P><FONT color=#0000ff face=Arial size=2><SPAN class=70452821-12012001>Where 
  is the Request-Contact header documented?</SPAN></FONT></P>
  <P><FONT color=#0000ff face=Arial size=2><SPAN 
  class=70452821-12012001>Thanks.</SPAN></FONT></P>
  <P><FONT color=#0000ff face=Arial size=2><SPAN class=70452821-12012001>-- Dai 
  Ngo&nbsp;</SPAN></FONT></P>
  <P>&nbsp;</P><BR><BR></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_q/i+Yy016s2Cbd3/MghVTA)--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 17:04:07 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25744
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 17:04:06 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CAD6044337; Fri, 12 Jan 2001 16:04:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cybertron.div8.net (HSE-Kitchener-ppp194551.sympatico.ca [64.229.13.138])
	by lists.bell-labs.com (Postfix) with ESMTP id 82BD444336
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 16:03:45 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m14HCJa-003ErdC@cybertron.div8.net> (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Fri, 12 Jan 2001 17:04:54 -0500 (EST) 
From: Billy Biggs <billy@billybiggs.com>
To: Jacek <Jacek_Grabiec@3com.com>
Cc: Juha Heinanen <jh@lohi.eng.telia.fi>, SIP List <sip@lists.bell-labs.com>
Subject: Proxy as Contact (was Re: [SIP] why is contact header mandatory invites and positive responses?)
Message-ID: <20010112170454.A1668@div8.net>
References: <882569D2.00566673.00@hqoutbound.ops.3com.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <882569D2.00566673.00@hqoutbound.ops.3com.com>; from Jacek_Grabiec@3com.com on Fri, Jan 12, 2001 at 09:43:21AM -0600
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 17:04:54 -0500

Jacek_Grabiec@3com.com (Jacek_Grabiec@3com.com):

> [...] or make your contact to be myua@proxy-to-go-through.com instead
> of IP address of your phone.
                          
  If your Contact address does not specify your client directly, then
you will have problems:

  1. The proxy server listed may act in redirect mode.  This is bad:
      - It may generate mid-call redirects, which breaks everything.
      - It may drop ACKs, since it can return a redirection response.

  2. The proxy may fork, which means we can't use the contact address 
     for attended transfer, etc...

  (1) is extremely evil.  Softclients on multi-homed PCs MUST ask the
user to pick an IP address from a list, or loop through the routing
table themselves (not possible in some languages ie. Java).

  In general, never use your well-known address as your Contact.

  Maybe we should mention this somewhere... ??

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 20:03:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27430
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 20:03:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CD4FB44337; Fri, 12 Jan 2001 19:04:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from longmail.lboard.com (mail.lboard.com [204.17.219.203])
	by lists.bell-labs.com (Postfix) with ESMTP id 3314844336
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 19:03:51 -0500 (EST)
Received: by LONGMAIL with Internet Mail Service (5.5.2650.21)
	id <C5VN43J3>; Fri, 12 Jan 2001 17:10:26 -0800
Message-ID: <C9C4E98B37CDD311BF320008C7088F1F4E4FBB@LONGMAIL>
From: Sekhar Banerjee <SBanerjee@lboard.com>
To: SIP List <sip@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Issue with BYE
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 17:10:25 -0800

Hi All,
	I have a wierd issue that I am facing in my call flows. While trying
to implement call forwarding I have come across a particular case which I
would like the experts to look at. 
	
	If phone A is trying to call phone B which has been forwarded to
phone C. When C hangs up the BYE from C to A doesnt have anything in the
message that would indicate that the message has come from phone C. Is there
any way in which we cna figure out where the message is comming from by
looking at the message ?

Thanks

Sekhar


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 20:41:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27761
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 20:41:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DAADA44348; Fri, 12 Jan 2001 19:42:03 -0500 (EST)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id 2D76344336
	for <sip@share.research.bell-labs.com>; Fri, 12 Jan 2001 19:41:30 -0500 (EST)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Jan 12 20:38:32 EST 2001
Received: by lists.bell-labs.com (Postfix)
	id 17F3244380; Fri, 12 Jan 2001 20:26:40 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5])
	by lists.bell-labs.com (Postfix) with SMTP id C4D244437D
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 20:26:39 -0500 (EST)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id TAA24365; Fri, 12 Jan 2001 19:26:35 -0600
Cc: SIP List <sip@lists.bell-labs.com>
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id TAA24358; Fri, 12 Jan 2001 19:26:32 -0600
Message-ID: <3A5FBF43.F60ACE01@lucent.com>
From: "Vijay K. Gurbani" <vkg@lucent.com>
Organization: Intelligent Network and Internet Software Group
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-6.1.1 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Sekhar Banerjee <SBanerjee@lboard.com>
Original-CC: SIP List <sip@lists.bell-labs.com>
Subject: Re: [SIP] Issue with BYE
References: <C9C4E98B37CDD311BF320008C7088F1F4E4FBB@LONGMAIL>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 20:36:51 -0600
Content-Transfer-Encoding: 7bit

Sekhar Banerjee wrote:
> 
> Hi All,
>         I have a wierd issue that I am facing in my call flows. While trying
> to implement call forwarding I have come across a particular case which I
> would like the experts to look at.
> 
>         If phone A is trying to call phone B which has been forwarded to
> phone C. When C hangs up the BYE from C to A doesnt have anything in the
> message that would indicate that the message has come from phone C. Is there
> any way in which we cna figure out where the message is comming from by
> looking at the message ?

The topmost Via in the BYE from C->A will have C's address.

- vijay
--
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software/IN Architecture Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713
0184

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Fri Jan 12 20:52:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27882
	for <sip-archive@odin.ietf.org>; Fri, 12 Jan 2001 20:52:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4BBD344354; Fri, 12 Jan 2001 19:53:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from longmail.lboard.com (mail.lboard.com [204.17.219.203])
	by lists.bell-labs.com (Postfix) with ESMTP id D72F744351
	for <sip@lists.bell-labs.com>; Fri, 12 Jan 2001 19:52:25 -0500 (EST)
Received: by LONGMAIL with Internet Mail Service (5.5.2650.21)
	id <C5VN43KY>; Fri, 12 Jan 2001 17:59:01 -0800
Message-ID: <C9C4E98B37CDD311BF320008C7088F1F4E4FBC@LONGMAIL>
From: Sekhar Banerjee <SBanerjee@lboard.com>
To: "'Vijay K. Gurbani'" <vkg@lucent.com>,
        Sekhar Banerjee <SBanerjee@lboard.com>
Cc: SIP List <sip@lists.bell-labs.com>
Subject: RE: [SIP] Issue with BYE
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 12 Jan 2001 17:59:00 -0800

Hi Vijay,
	It will surely have the address but it wont tell me anything about
the user right. I would like somehow to know that is is user agent C that is
sending the BYE message. Is there a way to get that detail from the message
?

Thanks

Sekhar

-----Original Message-----
From: Vijay K. Gurbani [mailto:vkg@lucent.com]
Sent: Friday, January 12, 2001 6:37 PM
To: Sekhar Banerjee
Cc: SIP List
Subject: Re: [SIP] Issue with BYE


Sekhar Banerjee wrote:
> 
> Hi All,
>         I have a wierd issue that I am facing in my call flows. While
trying
> to implement call forwarding I have come across a particular case which I
> would like the experts to look at.
> 
>         If phone A is trying to call phone B which has been forwarded to
> phone C. When C hangs up the BYE from C to A doesnt have anything in the
> message that would indicate that the message has come from phone C. Is
there
> any way in which we cna figure out where the message is comming from by
> looking at the message ?

The topmost Via in the BYE from C->A will have C's address.

- vijay
--
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software/IN Architecture Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713
0184

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Sun Jan 14 10:50:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08982
	for <sip-archive@odin.ietf.org>; Sun, 14 Jan 2001 10:50:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D25C74433A; Sun, 14 Jan 2001 09:51:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from panther.unisys.com.br (panther.unisys.com.br [200.220.64.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 41CF844336
	for <sip@lists.bell-labs.com>; Sun, 14 Jan 2001 09:50:43 -0500 (EST)
Received: from marcus (riopm18p34.unisys.com.br [200.220.16.34] (may be forged))
	by panther.unisys.com.br (8.11.1/8.11.1) with SMTP id f0EGoQf00843
	for <sip@lists.bell-labs.com>; Sun, 14 Jan 2001 13:50:27 -0300 (BDB)
From: "Marcus Vinicius" <vinicius@uninet.com.br>
To: <sip@lists.bell-labs.com>
Message-ID: <NEBBJJKNGLHPKCLKFJPDKEGCCAAA.vinicius@uninet.com.br>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Subject: [SIP] Location of users
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 14 Jan 2001 13:48:33 -0200
Content-Transfer-Encoding: 7bit

Dear Mr. ....,

	I'm a student, new to SIP, I'm trying to understand it and have some
questions.
	I think that one of the good aspects of SIP is the fact that any user can
be found in the network, wherever he is. Well, since he is registered in a
registrar in a domain.
	But let's imagine a user (that is usually found in
vinicius@correia.home.net) moves to the university where he studies, and now
is registered as vinicius@ic.uff.br. I think that an INVITE for him to the
domain correia.home.net will be redirected (by a location server) to the
domain he has moved to.
	My question is, how the location server in the domain correia.home.net
knows that the user moves to ic.uff.br as he can move anywhere? As that user
can be located anywhere, the user himself has to include as a list, the
possible domains he can be located? There is any procedure used among
location servers to inform each other the location of a user?


Thanks and Best regards,

Marcus Vinicius Ferreira Correia


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Sun Jan 14 20:25:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA11734
	for <sip-archive@odin.ietf.org>; Sun, 14 Jan 2001 20:25:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EC64D4433C; Sun, 14 Jan 2001 19:26:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
	by lists.bell-labs.com (Postfix) with ESMTP id 0806E4433A
	for <sip@lists.bell-labs.com>; Sun, 14 Jan 2001 19:25:30 -0500 (EST)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id SAA05260 for <sip@lists.bell-labs.com>; Sun, 14 Jan 2001 18:25:17 -0700 (MST)]
Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id SAA13778 for <sip@lists.bell-labs.com>; Sun, 14 Jan 2001 18:21:38 -0700 (MST)]
Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58)
	id <ZN1PJWWN>; Sun, 14 Jan 2001 19:25:16 -0600
Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED89E5@il27exm02.cig.mot.com>
From: Baniel Uri-CUB001 <Uri.Baniel@motorola.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] subset of media codecs
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 14 Jan 2001 19:25:15 -0600

RFC2543bis-02:

15.3

Note that Watson's list of codecs may or may not be a subset 
of the one offered by Bell, as each party indicates the data 
types it is willing to receive.

B2.
If the
   media stream is listed as both send and receive, the callee lists
   those codecs it is capable of sending or receiving among the ones
   listed by the caller in the INVITE. 
   If caller and callee have no media formats in common for a particular
   stream, the callee MUST return a session description containing the
   particular "m=" line, but with the port number set to zero. 

Which one is the correct one? I tend to go with B2...

Uri

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Sun Jan 14 21:31:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12274
	for <sip-archive@odin.ietf.org>; Sun, 14 Jan 2001 21:31:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F306A4433A; Sun, 14 Jan 2001 20:32:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cybertron.div8.net (HSE-Kitchener-ppp194240.sympatico.ca [64.229.12.81])
	by lists.bell-labs.com (Postfix) with ESMTP id 32D2644336
	for <sip@lists.bell-labs.com>; Sun, 14 Jan 2001 20:31:36 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m14HzS2-003ErdC@cybertron.div8.net> (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Sun, 14 Jan 2001 21:32:54 -0500 (EST) 
From: Billy Biggs <billy@billybiggs.com>
To: Baniel Uri-CUB001 <Uri.Baniel@motorola.com>
Cc: SIP List <sip@lists.bell-labs.com>
Subject: Re: [SIP] subset of media codecs
Message-ID: <20010114213254.A446@div8.net>
References: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED89E5@il27exm02.cig.mot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED89E5@il27exm02.cig.mot.com>; from Uri.Baniel@motorola.com on Sun, Jan 14, 2001 at 07:25:15PM -0600
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 14 Jan 2001 21:32:54 -0500

Baniel Uri-CUB001 (Uri.Baniel@motorola.com):

> RFC2543bis-02:
> 15.3
>   Note that Watson's list of codecs may or may not be a subset of the
>   one offered by Bell, as each party indicates the data types it is
>   willing to receive.
> 
> B2.
>   If the media stream is listed as both send and receive, the callee
>   lists those codecs it is capable of sending or receiving among the
>   ones listed by the caller in the INVITE.  If caller and callee have
>   no media formats in common for a particular stream, the callee MUST
>   return a session description containing the particular "m=" line,
>   but with the port number set to zero. 
> 
> Which one is the correct one? I tend to go with B2...

  You always return all of the codecs you can receive.

  This came up at the bakeoff with RFC2833 RTP DTMF digits.  Most phones
can send these types of RTP digits, but not receive them.  If a gateway
receives an INVITE that only lists G.711 audio, should it advertise that
it supports RFC2833 tones?  If you only send a subset of what you
receive, then only G.711 gets listed.  Clearly, this is broken.

  Another example is with a back-to-back UA.  It may first answer with a
token audio format, say G.711, then later update with a full codec
listing from whomever it subsequently connects with.  The roles of who
should send a subset of what are now completely meaningless.

  Best to always advertise all the codecs you can receive, thus avoiding
all problems.

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Sun Jan 14 23:30:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14808
	for <sip-archive@odin.ietf.org>; Sun, 14 Jan 2001 23:30:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2C4B14434C; Sun, 14 Jan 2001 22:31:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from hindon.hss.co.in (unknown [202.54.26.202])
	by lists.bell-labs.com (Postfix) with ESMTP id C0D0A44336
	for <sip@lists.bell-labs.com>; Sun, 14 Jan 2001 22:30:47 -0500 (EST)
Received: from hsssun01.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f0F4Vrg08518
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 10:01:53 +0530 (IST)
Received: from sampark.hss.hns.com (sampark [139.85.229.22])
	by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id f0F4dmY00224
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 10:09:53 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 652569D5.0018EA99 ; Mon, 15 Jan 2001 10:02:09 +0530
X-Lotus-FromDomain: HSSBLR
From: kbinu@hss.hns.com
To: sip@lists.bell-labs.com
Message-ID: <652569D5.0018EA83.00@sampark.hss.hns.com>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Subject: [SIP] Stateless proxy handling for looped requests
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 15 Jan 2001 10:02:08 +0530



Hi,

Does a stateless proxy always forward every request it receives ? What
about requests that have looped or have a max-forwards indicating 0 ? Can
it generate responses to such requests ? Is a stateless proxy allowed to
send "Forbidden" response to requests from a particular user or domain ?

If a stateless proxy does respond to such requests with "Loop Detected" or
"Too Many Hops" responses, should these responses be retransmitted if the
request was an INVITE ?

I have another doubt about the Allow header. Since a proxy forwards
requests of any kind, what are the methods that it adds in the Allow
headers if it needs to respond to an OPTIONS request ?

Regards,
Binu



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan 15 03:27:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29593
	for <sip-archive@odin.ietf.org>; Mon, 15 Jan 2001 03:27:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3C08744341; Mon, 15 Jan 2001 02:28:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102])
	by lists.bell-labs.com (Postfix) with ESMTP id 9C06E44336
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 02:27:57 -0500 (EST)
Received: from spiderman.cwc.nus.edu.sg ([172.16.3.239])
	by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with ESMTP id QAA12585
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 16:22:25 +0800 (SGT)
Message-Id: <4.3.2.7.2.20010115161323.00a9cba0@postman.cwc.nus.edu.sg>
X-Sender: tansk@postman.cwc.nus.edu.sg
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: sip@lists.bell-labs.com
From: Tan Seng Kee <tansk@cwc.nus.edu.sg>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] What is LoadGen_On in ua.cfg file ?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 15 Jan 2001 16:17:56 +0800

Hi,

I am trying to understand the SIP code. Does any one has any idea about the 
option of "LoadGen_On" in the config file and what is the purpose of this 
setting ?

Thank you.

Tan Seng Kee


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan 15 04:13:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29879
	for <sip-archive@odin.ietf.org>; Mon, 15 Jan 2001 04:13:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 02C2644341; Mon, 15 Jan 2001 03:14:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id 7D12744336
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 03:13:54 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 15 Jan 2001 09:13:42 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id JAA01030; Mon, 15 Jan 2001 09:12:26 GMT
From: "Jo Hornsby" <jhornsby@ubiquity.net>
To: "Pizzimenti, Joe" <Joe.Pizzimenti@wcom.com>, <sip@lists.bell-labs.com>
Subject: RE: [SIP] Contact in proxy non 407 response
Message-ID: <000601c07ed3$4741fcc0$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <492EB4A3F68CD411ABE800508B69362E239507@RIPEXCH002.wcomnet.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 15 Jan 2001 09:12:26 -0000
Content-Transfer-Encoding: 7bit

Joe Pizzimenti wrote:
> I recently ran across this question and after looking at the 02
> bis, I would like opinions regarding the following. 
>
> Should a 407 proxy response include the Contact header that was
> in the original INVITE?

No.

> Should the proxy remove the contact header/headers that are in
> the original INVITE? or may the proxy return the Contact header(s)
> found in the original INVITE?

When a proxy generates a response, it should copy
{From, To, Call-ID, CSeq, Vias} from the corresponding request.
In general, that is all.

> There have been discussions on the list with the title of why
> is contact header mandatory invites and positiveresponses but
> nothing about whether a proxy may or may not return the Contacts
> that were sent in the request, in the 407 response.

The dodgy thing about doing this is that a Contact in a non-2xx
or non-3xx response is supposed to indicate somewhere where
further error information may be obtained.  For example, a
gateway might add something like:
    Contact: sip:caller-busy@announcement-servers.sipfarm.net
if the destination you were calling was busy.

HTH,


 - Jo.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan 15 04:39:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29989
	for <sip-archive@odin.ietf.org>; Mon, 15 Jan 2001 04:39:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2BA034435F; Mon, 15 Jan 2001 03:40:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id BAAAB44341
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 03:39:00 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 15 Jan 2001 09:38:48 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id JAA10100; Mon, 15 Jan 2001 09:37:32 GMT
From: "Jo Hornsby" <jhornsby@ubiquity.net>
To: <kbinu@hss.hns.com>, <sip@lists.bell-labs.com>
Subject: RE: [SIP] Stateless proxy handling for looped requests
Message-ID: <000701c07ed6$c909aed0$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <652569D5.0018EA83.00@sampark.hss.hns.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 15 Jan 2001 09:37:32 -0000
Content-Transfer-Encoding: 7bit

First, look at: http://www.cs.columbia.edu/%7Ehgs/sip/faq/cache/36.html
Bearing this in mind....

> Does a stateless proxy always forward every request it receives ? What
> about requests that have looped or have a max-forwards indicating 0 ? Can
> it generate responses to such requests ? Is a stateless proxy allowed to
> send "Forbidden" response to requests from a particular user or domain ?

A proxy that is behaving stateless does not generate responses.
In cases such as these, the proxy would have to respond in a
stateful fashion.

> If a stateless proxy does respond to such requests with "Loop Detected" or
> "Too Many Hops" responses, should these responses be retransmitted if the
> request was an INVITE ?

Yes.

> I have another doubt about the Allow header. Since a proxy forwards
> requests of any kind, what are the methods that it adds in the Allow
> headers if it needs to respond to an OPTIONS request ?

When a "proxy" responds to an OPTIONS, it is not responding as a
proxy, but as a server.  Therefore, I would imagine a SIP proxy-like
entity that always behaved statelessly (except in the error cases
you listed above) would respond to OPTIONS with
  Allow: ACK, CANCEL
Alternatively, a chimeric beast consisting of a registrar and proxy
would respond with
  Allow: ACK, CANCEL, REGISTER

Cheers,


 - Jo.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan 15 05:20:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA00212
	for <sip-archive@odin.ietf.org>; Mon, 15 Jan 2001 05:20:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C7D7244339; Mon, 15 Jan 2001 04:21:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 7952344336
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 04:20:38 -0500 (EST)
Received: by ztxmail03.ztx.compaq.com (Postfix, from userid 12345)
	id 47C538B1; Mon, 15 Jan 2001 04:20:26 -0600 (CST)
Received: from excmun-gh02.eur.compaq.com (excmun-gh02.dem.cpqcorp.net [16.41.92.161])
	by ztxmail03.ztx.compaq.com (Postfix) with ESMTP
	id 4A636B4D; Mon, 15 Jan 2001 04:20:25 -0600 (CST)
Received: by excmun-gh02.dem.cpqcorp.net with Internet Mail Service (5.5.2650.21)
	id <C0TCG6GH>; Mon, 15 Jan 2001 11:20:23 +0100
Message-ID: <C1434589DE6ED411885900508BDF604D0A038C@vbeexc01.vbe.cpqcorp.net>
From: "Rolland, Frederic" <Frederic.Rolland@Compaq.com>
To: "'Marcus Vinicius'" <vinicius@uninet.com.br>
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Location of users
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 15 Jan 2001 11:20:16 +0100

Hi Marcus,
your question addresses one typical example of personal mobility management.
when you're located in a foreign remote network (in contrast with your home
network),
you must register *locally* (foreign network) in order to tell the local
proxy you're here
and allowing it to forward messages to you, *and* register to your home
network to indicate
your current location to where message must be forwarded to..
so, first message take this path:
source-->home network proxy-->foreign network proxy-->you

this is the same model of personal mobility management that can be found in
the IP Mobility framework...

an example can be found slide 157 in "The Session Initiation Protocol" by
Henning Schulzrinne
http://www.cs.columbia.edu/~hgs

see you,
Frederic.

!!-: -----Original Message-----
!!-: From: Marcus Vinicius [mailto:vinicius@uninet.com.br]
!!-: Sent: Sunday, January 14, 2001 4:49 PM
!!-: To: sip@lists.bell-labs.com
!!-: Subject: [SIP] Location of users
!!-: 
!!-: 
!!-: Dear Mr. ....,
!!-: 
!!-: 	I'm a student, new to SIP, I'm trying to understand it 
!!-: and have some
!!-: questions.
!!-: 	I think that one of the good aspects of SIP is the fact 
!!-: that any user can
!!-: be found in the network, wherever he is. Well, since he is 
!!-: registered in a
!!-: registrar in a domain.
!!-: 	But let's imagine a user (that is usually found in
!!-: vinicius@correia.home.net) moves to the university where 
!!-: he studies, and now
!!-: is registered as vinicius@ic.uff.br. I think that an 
!!-: INVITE for him to the
!!-: domain correia.home.net will be redirected (by a location 
!!-: server) to the
!!-: domain he has moved to.
!!-: 	My question is, how the location server in the domain 
!!-: correia.home.net
!!-: knows that the user moves to ic.uff.br as he can move 
!!-: anywhere? As that user
!!-: can be located anywhere, the user himself has to include 
!!-: as a list, the
!!-: possible domains he can be located? There is any procedure 
!!-: used among
!!-: location servers to inform each other the location of a user?
!!-: 
!!-: 
!!-: Thanks and Best regards,
!!-: 
!!-: Marcus Vinicius Ferreira Correia
!!-: 
!!-: 
!!-: _______________________________________________
!!-: SIP mailing list
!!-: SIP@lists.bell-labs.com
!!-: http://lists.bell-labs.com/mailman/listinfo/sip
!!-: 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan 15 09:51:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06578
	for <sip-archive@odin.ietf.org>; Mon, 15 Jan 2001 09:51:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A85C344339; Mon, 15 Jan 2001 08:52:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
	by lists.bell-labs.com (Postfix) with ESMTP id 0C88244336
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 08:51:36 -0500 (EST)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-blue.research.att.com (Postfix) with ESMTP id 796DD4CE0E
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 09:51:20 -0500 (EST)
Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id JAA14135
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 09:51:19 -0500 (EST)
From: William Marshall <wtm@research.att.com>
Received: (from wtm@localhost)
	by fish-ha.research.att.com (SGI-8.9.3/8.8.5) id JAA76544
	for sip@lists.bell-labs.com; Mon, 15 Jan 2001 09:51:37 -0500 (EST)
Message-Id: <200101151451.JAA76544@fish-ha.research.att.com>
To: sip@lists.bell-labs.com
Subject: [SIP] Re: Issue with BYE
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 15 Jan 2001 09:51:37 -0500 (EST)

You might take a look at draft-ietf-sip-privacy-00.  The Remote-Party-ID
header is intended to tell A the identity of the subscriber that actually
answered (in your case, C) in the first non-100 response to the INVITE.
Of course, this is subject to various privacy restrictions, like whether
C wants their identity blocked, or whether B wants the forwarding 
information revealed.

But, all that information comes in the INVITE.  In the BYE message itself, 
best clue is the Via values.

Bill Marshall
wtm@research.att.com

-----original message-----
From: Sekhar Banerjee <SBanerjee@lboard.com>
To: SIP List <sip@lists.bell-labs.com>
Subject: [SIP] Issue with BYE
Date: Fri, 12 Jan 2001 17:10:25 -0800

Hi All,
	I have a wierd issue that I am facing in my call flows. While trying
to implement call forwarding I have come across a particular case which I
would like the experts to look at. 
	
	If phone A is trying to call phone B which has been forwarded to
phone C. When C hangs up the BYE from C to A doesnt have anything in the
message that would indicate that the message has come from phone C. Is there
any way in which we cna figure out where the message is comming from by
looking at the message ?

Thanks

Sekhar


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan 15 10:08:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07048
	for <sip-archive@odin.ietf.org>; Mon, 15 Jan 2001 10:08:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B5E814434A; Mon, 15 Jan 2001 09:09:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from guardian1.tlv.radvision.com (unknown [212.143.185.30])
	by lists.bell-labs.com (Postfix) with ESMTP id F25F844336
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 09:08:39 -0500 (EST)
Received: from nt-mail.tlv.radvision.com ([172.20.2.100])
          by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3
          release 223 ID# 0-0U10L2S100V35) with ESMTP id com;
          Mon, 15 Jan 2001 18:06:01 +0200
Received: by NT-MAIL with Internet Mail Service (5.5.2650.21)
	id <C96KA97Q>; Mon, 15 Jan 2001 17:10:25 +0200
Message-ID: <E09383987EE5D3119F2E0008C7097728014D7542@NT-MAIL>
From: Itamar Gilad <ItamarG@tlv.radvision.com>
To: "'Sekhar Banerjee'" <SBanerjee@lboard.com>,
        SIP List <sip@lists.bell-labs.com>
Subject: RE: [SIP] Issue with BYE
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 15 Jan 2001 17:10:24 +0200

When C accepted the call it sent a Contact header in the 2xx response (this
is a MUST in bis-02). The Contact is "indicating the SIP address under which
it is reachable most directly" (2.6).

  Itamar

> -----Original Message-----
> From: Sekhar Banerjee [mailto:SBanerjee@lboard.com]
> Sent: Sat, January 13, 2001 3:10 AM
> To: SIP List
> Subject: [SIP] Issue with BYE
> 
> 
> Hi All,
> 	I have a wierd issue that I am facing in my call flows. 
> While trying
> to implement call forwarding I have come across a particular 
> case which I
> would like the experts to look at. 
> 	
> 	If phone A is trying to call phone B which has been forwarded to
> phone C. When C hangs up the BYE from C to A doesnt have 
> anything in the
> message that would indicate that the message has come from 
> phone C. Is there
> any way in which we cna figure out where the message is 
> comming from by
> looking at the message ?
> 
> Thanks
> 
> Sekhar
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan 15 10:23:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07346
	for <sip-archive@odin.ietf.org>; Mon, 15 Jan 2001 10:23:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F2FA644339; Mon, 15 Jan 2001 09:24:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailgw3.netvision.net.il (mailgw3.netvision.net.il [194.90.1.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 564EF44336
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 09:23:50 -0500 (EST)
Received: from ismailout.icomverse.com (efratgw.icomverse.com [199.203.140.6])
	by mailgw3.netvision.net.il (8.9.3/8.9.3) with ESMTP id RAA21080
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 17:22:24 +0200 (IST)
Received: from ismail-bridge.icomverse.com (ismail-bridge.icomverse.com [190.190.110.12])
	by ismailout.icomverse.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id f0FFNA913782
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 17:23:16 +0200
Received: by ismail-bridge.icomverse.com with Internet Mail Service (5.5.2653.19)
	id <CXVKFHW3>; Mon, 15 Jan 2001 17:23:13 +0200
Message-ID: <82F3693D2F88D411B91600508BE3518E017948FF@ismailweb.icomverse.com>
From: "Levkovitz, Zohar" <Zohar_Levkovitz@icomverse.com>
To: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
Subject: [SIP] 3GPP
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 15 Jan 2001 17:21:57 +0200

May anyone have the 3GPP decisions about SIP?

Levkovitz Zohar
Comverse Network Systems



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan 15 10:50:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07801
	for <sip-archive@odin.ietf.org>; Mon, 15 Jan 2001 10:50:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 651C34434A; Mon, 15 Jan 2001 09:51:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.northstream.se (unknown [62.20.120.194])
	by lists.bell-labs.com (Postfix) with SMTP id 38DF944336
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 09:50:17 -0500 (EST)
Received: from exchange.northstream.se by mail.northstream.se
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 15 Jan 2001 15:50:04 UT
Received: by exchange.northstream.se with Internet Mail Service (5.5.2650.21)
	id <CJ4YQ35G>; Mon, 15 Jan 2001 16:49:40 +0100
Message-ID: <93E299DA8B7DD411904300D0B7D4834305CEBF@exchange.northstream.se>
From: Jerome Privat <jerome.privat@northstream.se>
To: "'Levkovitz, Zohar'" <Zohar_Levkovitz@icomverse.com>,
        "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
Subject: RE: [SIP] 3GPP
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="WINDOWS-1255"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 15 Jan 2001 16:49:37 +0100

You can have a look at 3G TS 23.228 available from the 3GPP web site at:
http://www.3gpp.org/ftp/Specs/2000-12/Drafts/23_series/

Jerome Privat
Northstream AB
http://www.northstream.se



-----Original Message-----
From: Levkovitz, Zohar [mailto:Zohar_Levkovitz@icomverse.com]
Sent: Monday, January 15, 2001 4:22 PM
To: 'sip@lists.bell-labs.com'
Subject: [SIP] 3GPP


May anyone have the 3GPP decisions about SIP?

Levkovitz Zohar
Comverse Network Systems



_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan 15 11:26:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09317
	for <sip-archive@odin.ietf.org>; Mon, 15 Jan 2001 11:26:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8122844339; Mon, 15 Jan 2001 10:27:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailgw1.netvision.net.il (mailgw1.netvision.net.il [194.90.1.14])
	by lists.bell-labs.com (Postfix) with ESMTP id 21BBA44336
	for <SIP@lists.bell-labs.com>; Mon, 15 Jan 2001 10:26:45 -0500 (EST)
Received: from ismailout.icomverse.com (efratgw.icomverse.com [199.203.140.6])
	by mailgw1.netvision.net.il (8.9.3/8.9.3) with ESMTP id SAA15009
	for <SIP@lists.bell-labs.com>; Mon, 15 Jan 2001 18:26:30 +0200 (IST)
Received: from ismailmkt.icomverse.com (ismailmkt.icomverse.com [190.190.55.28])
	by ismailout.icomverse.com (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id f0FGQB915648
	for <SIP@lists.bell-labs.com>; Mon, 15 Jan 2001 18:26:16 +0200
Received: by ismailmkt.icomverse.com with Internet Mail Service (5.5.2650.21)
	id <CVX8R1T8>; Mon, 15 Jan 2001 18:24:34 +0200
Received: from ismaildev.icomverse.com ([190.190.110.5]) by ismail3.icomverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id CT5S6LDG; Mon, 15 Jan 2001 18:24:40 +0200
Received: by ismaildev.icomverse.com with Internet Mail Service (5.5.2650.21)
	id <CTAHY92F>; Mon, 15 Jan 2001 18:25:43 +0200
Received: from ismaildev.icomverse.com ([190.190.110.5]) by ismail3.icomverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id CT5S6LD1; Mon, 15 Jan 2001 18:24:30 +0200
Received: by ismaildev.icomverse.com with Internet Mail Service (5.5.2650.21)
	id <CTAHY92C>; Mon, 15 Jan 2001 18:25:33 +0200
From: "Levkovitz, Zohar" <Zohar_Levkovitz@icomverse.com>
To: "'SIP@lists.bell-labs.com'" <SIP@lists.bell-labs.com>
Message-ID: <82F3693D2F88D411B91600508BE3518E01794901@ismailweb.icomverse.com>
Subject: [SIP] another May
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="windows-1255"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 15 Jan 2001 18:24:38 +0200

May anyone have anything about PUSH mechanism using SIP in 3GPP

Levkovitz Zohar
Comverse Network Systems


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan 15 13:06:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12632
	for <sip-archive@odin.ietf.org>; Mon, 15 Jan 2001 13:06:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 39DFF44339; Mon, 15 Jan 2001 12:07:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 6D4A044336
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 10:40:53 -0500 (EST)
Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA05261;
	Mon, 15 Jan 2001 08:40:51 -0800 (PST)
Received: from jeffgaow2k (dhcp-128-107-142-93.cisco.com [128.107.142.93])
	by mira-sjc5-1.cisco.com (Mirapoint)
	with SMTP id AHG03672;
	Mon, 15 Jan 2001 08:40:31 -0800 (PST)
From: "Jeff Gao" <jeffgao@cisco.com>
To: "'Tan Seng Kee'" <tansk@cwc.nus.edu.sg>, <sip@lists.bell-labs.com>
Subject: RE: [SIP] What is LoadGen_On in ua.cfg file ?
Message-ID: <000a01c07f11$da219760$5d8e6b80@cisco.com>
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 CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <4.3.2.7.2.20010115161323.00a9cba0@postman.cwc.nus.edu.sg>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 15 Jan 2001 08:40:20 -0800
Content-Transfer-Encoding: 7bit

Tan Seng,

US can also be used as a load generator to stree test proxy servers or
another endpoints.  By setting LoadGen_On to true, UA will automatically
initate calls to a fixed destination at pre-determined time interval.  It
can also be configured to be on the receiving end of the call.  Hope this
helps.

Regards,

Jeff Gao
Cisco Systems

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Tan Seng Kee
> Sent: Monday, January 15, 2001 12:18 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] What is LoadGen_On in ua.cfg file ?
>
>
> Hi,
>
> I am trying to understand the SIP code. Does any one has any
> idea about the
> option of "LoadGen_On" in the config file and what is the
> purpose of this
> setting ?
>
> Thank you.
>
> Tan Seng Kee
>
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan 15 14:52:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14679
	for <sip-archive@odin.ietf.org>; Mon, 15 Jan 2001 14:52:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C614A44339; Mon, 15 Jan 2001 13:53:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 33D8144336
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 13:52:06 -0500 (EST)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA20629
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 11:52:03 -0800 (PST)
Received: from buckthorn-nt.cisco.com (dhcp-128-107-142-87.cisco.com [128.107.142.87])
	by imop.cisco.com (Mirapoint)
	with ESMTP id AAH26550 (AUTH rmahy);
	Mon, 15 Jan 2001 11:51:53 -0800 (PST)
Message-Id: <5.0.0.25.2.20010115114451.0245cc60@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
To: sip@lists.bell-labs.com
From: Rohan Mahy <rohan@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] Need rough count for interim meeting
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 15 Jan 2001 11:50:30 -0800

Hi,

I need a rough count of those attending in person and by phone, so I can 
reserve the rooms / conference bridge, etc..

Please reply privately to me (or click on the links below) and I will post 
a count back to the list.
	mailto:rohan@cisco.com?subject=AttendingInterimSIPmeeting

	mailto:rohan@cisco.com?subject=CallingInterimSIPmeeting

thanks,
-rohan


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan 15 23:31:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22269
	for <sip-archive@odin.ietf.org>; Mon, 15 Jan 2001 23:31:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A22EA44339; Mon, 15 Jan 2001 22:32:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web10305.mail.yahoo.com (web10305.mail.yahoo.com [216.136.130.83])
	by lists.bell-labs.com (Postfix) with SMTP id 7A32A44336
	for <SIP@lists.bell-labs.com>; Mon, 15 Jan 2001 22:31:13 -0500 (EST)
Message-ID: <20010116043101.62277.qmail@web10305.mail.yahoo.com>
Received: from [203.200.4.159] by web10305.mail.yahoo.com; Mon, 15 Jan 2001 20:31:01 PST
From: james jack <sipjames@yahoo.com>
To: SIP@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] Some idea on Stateful SIP Proxy
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 15 Jan 2001 20:31:01 -0800 (PST)

Dear All:
   I have one foolish idea on stateful SIP Proxy.
   For some service on SIP, for example, card service,
if card A has account of 40$,assumed that one minute
costs 1$, then the time for this card user to
communicate is only 40 minutes.
   Supposed a card user use this card for
communication, when 40 minutes passed, the application

layer of Proxy should send BYE request to caller 
and callee. Otherwise, how can the system stop
communication. Then under this situatuion, I think the
stateful proxy should send out BYE request. That is, I
think on RFC 2543, it should add that the stateful
proxy can send BYE.
    Any suggestion and idea are welcome!
    Best Regards!
                        Yours:james!


   This is my idea, 

 

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan 15 23:40:50 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22315
	for <sip-archive@odin.ietf.org>; Mon, 15 Jan 2001 23:40:50 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EBF2944361; Mon, 15 Jan 2001 22:41:02 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from hotmail.com (f172.pav1.hotmail.com [64.4.31.172])
	by lists.bell-labs.com (Postfix) with ESMTP id 9988644336
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 22:40:36 -0500 (EST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Mon, 15 Jan 2001 20:40:23 -0800
Received: from 202.177.128.86 by pv1fd.pav1.hotmail.msn.com with HTTP;	Tue, 16 Jan 2001 04:40:23 GMT
X-Originating-IP: [202.177.128.86]
From: "Rakesh Jain" <rak_jain@hotmail.com>
To: sip@lists.bell-labs.com
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F172JY4kJSFsxf4yp8A00003280@hotmail.com>
X-OriginalArrivalTime: 16 Jan 2001 04:40:23.0950 (UTC) FILETIME=[70AB0AE0:01C07F76]
Subject: [SIP] LWS grammar.....
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 04:40:23 -0000


   Hi,
        I am having some doubt on LWS grammar,
        It is
            LWS = *(SP|HT) [CRLF] 1*(SP|HT)

        Can someone tell me what is the significance of putting
        [CRLF] here, It will allow to have CRLF in message header's
        field-value. It can come in between also.

        from RFC2543
           message-header  =  field-name ":" [ field-value ] CRLF
           field-name      =  token
           field-value     =  *( field-content | LWS )
           field-content   =  < the OCTETs  making up the field-value
                              and consisting of either *TEXT-UTF8
                              or combinations of token,
                              separators, and quoted-string>

        And whenever CRLF is coming ( not the final one ), it will give
        impression of ending of the header field value, which is not
        actually. Is it OK or I am missing something. Or special care
        should be taken to avoid CRLF in between field-value.

        I am sorry, if same question had been asked previously.
        thanks....

  rakesh





_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Mon Jan 15 23:42:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22342
	for <sip-archive@odin.ietf.org>; Mon, 15 Jan 2001 23:42:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5DAC144369; Mon, 15 Jan 2001 22:41:10 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cybertron.div8.net (HSE-Kitchener-ppp114741.sympatico.ca [216.209.177.84])
	by lists.bell-labs.com (Postfix) with ESMTP id 85AC744336
	for <SIP@lists.bell-labs.com>; Mon, 15 Jan 2001 22:40:40 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m14INwb-003ErcC@cybertron.div8.net> (Debian Smail3.2.0.102)
	for SIP@lists.bell-labs.com; Mon, 15 Jan 2001 23:42:05 -0500 (EST) 
From: Billy Biggs <billy@billybiggs.com>
To: james jack <sipjames@yahoo.com>
Cc: SIP@lists.bell-labs.com
Subject: Re: [SIP] Some idea on Stateful SIP Proxy
Message-ID: <20010115234205.A1846@div8.net>
References: <20010116043101.62277.qmail@web10305.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010116043101.62277.qmail@web10305.mail.yahoo.com>; from sipjames@yahoo.com on Mon, Jan 15, 2001 at 08:31:01PM -0800
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 15 Jan 2001 23:42:05 -0500

james jack (sipjames@yahoo.com):

> I have one foolish idea on stateful SIP Proxy.  For some service on
> SIP, for example, card service, if card A has account of 40$,assumed
> that one minute costs 1$, then the time for this card user to
> communicate is only 40 minutes.  Supposed a card user use this card
> for communication, when 40 minutes passed, the application layer of
> Proxy should send BYE request to caller and callee. Otherwise, how can
> the system stop communication. Then under this situatuion, I think the
> stateful proxy should send out BYE request. That is, I think on RFC
> 2543, it should add that the stateful proxy can send BYE.

  A proxy cannot send a BYE.

  To perform this behavior you must use a back-to-back UA.

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 00:20:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22673
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 00:20:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AFC8B44357; Mon, 15 Jan 2001 23:21:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from hindon.hss.co.in (unknown [202.54.26.202])
	by lists.bell-labs.com (Postfix) with ESMTP id E280344339
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 23:19:57 -0500 (EST)
Received: from hsssun01.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f0G5L5202621;
	Tue, 16 Jan 2001 10:51:06 +0530 (IST)
Received: from sampark.hss.hns.com (sampark [139.85.229.22])
	by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id f0G5SvY23484;
	Tue, 16 Jan 2001 10:59:02 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 652569D6.001D6936 ; Tue, 16 Jan 2001 10:51:14 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: "Rakesh Jain" <rak_jain@hotmail.com>
Cc: sip@lists.bell-labs.com
Message-ID: <652569D6.001D678F.00@sampark.hss.hns.com>
Subject: Re: [SIP] LWS grammar.....
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 10:51:10 +0530



The CRLF is for line folding - that is , a header can be broken up into
multiple lines as long as the continuation
line starts with one or more space/tab

example:

From: me@you.com; foo=1; shoo=2

AND

From:
     me@you.com;
          foo=1;
     shoo=2

are both allowed

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems





"Rakesh Jain" <rak_jain@hotmail.com> on 01/16/2001 10:10:23 AM

To:   sip@lists.bell-labs.com
cc:

Subject:  [SIP] LWS grammar.....





   Hi,
        I am having some doubt on LWS grammar,
        It is
            LWS = *(SP|HT) [CRLF] 1*(SP|HT)

        Can someone tell me what is the significance of putting
        [CRLF] here, It will allow to have CRLF in message header's
        field-value. It can come in between also.

        from RFC2543
           message-header  =  field-name ":" [ field-value ] CRLF
           field-name      =  token
           field-value     =  *( field-content | LWS )
           field-content   =  < the OCTETs  making up the field-value
                              and consisting of either *TEXT-UTF8
                              or combinations of token,
                              separators, and quoted-string>

        And whenever CRLF is coming ( not the final one ), it will give
        impression of ending of the header field value, which is not
        actually. Is it OK or I am missing something. Or special care
        should be taken to avoid CRLF in between field-value.

        I am sorry, if same question had been asked previously.
        thanks....

  rakesh





_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip





_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 00:41:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22937
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 00:41:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3381E44339; Mon, 15 Jan 2001 23:42:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from longmail.lboard.com (mail.lboard.com [204.17.219.203])
	by lists.bell-labs.com (Postfix) with ESMTP id 7A7C344336
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 23:41:05 -0500 (EST)
Received: by longmail.lboard.com with Internet Mail Service (5.5.2650.21)
	id <DA7QAN30>; Mon, 15 Jan 2001 21:47:47 -0800
Message-ID: <C9C4E98B37CDD311BF320008C7088F1F4E4FC5@longmail.lboard.com>
From: Sekhar Banerjee <SBanerjee@lboard.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Presence of * in Contact Header
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 15 Jan 2001 21:47:46 -0800

Hi All,
	I would like to get a consensus on this issue from the SIP
implementors on this list. Is the contact header
	
Contact:	*69 <sip:123456@10.1.2.2:5060>
	
	a valid contact header. I have had one side say that since the * has
a special meaning in the Contact header and hence there shouldnt be anything
else in that header. The other opinion is that since
the Contact Header contains more than the * hence there isnt anything wrong
with it and the stack should parse it all.
	What is the correct way of handling this ?


Thanks

Sekhar Banerjee

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 00:44:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23059
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 00:44:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 301DC44374; Mon, 15 Jan 2001 23:45:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 95AC344371
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 23:44:03 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA13280;
	Tue, 16 Jan 2001 00:46:33 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KH74B>; Tue, 16 Jan 2001 00:40:36 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB0CE@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Paul Francis'" <paul@francis.com>,
        "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
        Neil Deason <ndeason@ubiquity.net>
Cc: Jo Hornsby <jhornsby@ubiquity.net>, sip@lists.bell-labs.com
Subject: RE: [SIP] question on received tag in via header,draft-ietf-sip-r
	fc2543bis-02.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 00:40:34 -0500



 

> -----Original Message-----
> From: Paul Francis [mailto:yoid2000@pacbell.net]
> Sent: Monday, January 08, 2001 3:01 PM
> To: Henning G. Schulzrinne; Neil Deason
> Cc: Jo Hornsby; Paul Francis; sip@lists.bell-labs.com
> Subject: Re: [SIP] question on received tag in via
> header,draft-ietf-sip-rfc2543bis-02.txt
> 
> > > I would further ask that we simply the SIP spec in this area.
> > > 6.47.1 Requests (p.77) and 6.47.2 Receiver-tagged Via Header
> > > Fields (p.78) both contain text about adding the received
> > > parameter. In 6.47.2 this crops up in relation to NATs. As the
> > > received param alone will not solve NAT issues can this
> > > reference be removed and these two sections consolidated into
> > > one?
> >
> > I've combined the material into 6.47.2 and made up a 
> multi-homed example
> > rather than a NAT example, removing mention of NATs altogether.
> 
> This strikes me as potentially not adequately addressing the 
> issue, for two
> reasons.
>
> Second, it seems to me that if you really did not want to use 
> this for any
> kind of NAT, then I would question whether it would be better 
> to remove the
> received tag altogether, on the basis that the multihomed 
> case is such a
> corner case that it isn't worth putting the tag in the via 
> header.  The
> reasoning here is that the SIP implementation can certainly 
> arrange to know
> what the source address on the IP packet is going to be, so 
> it can also
> arrange to put the same address in the SIP header.

In practice, it seems to be much, much harder to do this than you might
think. Part of it has to do with a separation of protocol layering that we'd
like to have. Its good to be able to build a stack where the socket and
network I/O issues happen last, after the sip message formatting and sip
machinery has done its job. Secondly, its just not easy to obtain the source
address where the packet will go. There are definitely issues in having this
work ubiquitously across operating systems, machines, and languages.

Also, I think it will be quite common for a host to be multihomed, and to
not be reachable from any host on both networks. The classic case are users
who connect to work through VPNs. 

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 00:52:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23095
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 00:52:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6809344369; Mon, 15 Jan 2001 23:53:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id DB8F944368
	for <sip@lists.bell-labs.com>; Mon, 15 Jan 2001 23:52:51 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA13321;
	Tue, 16 Jan 2001 00:52:13 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KH74L>; Tue, 16 Jan 2001 00:46:16 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB0CF@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Deepak  Mohan'" <deepakwarrier@rediffmail.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] OPTIONS method, bug in draft-ietf-sip-rfc2543bis-02
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 00:46:06 -0500



 

> -----Original Message-----
> From: Deepak Mohan [mailto:deepakwarrier@rediffmail.com]
> Sent: Tuesday, January 09, 2001 6:26 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] OPTIONS method, bug in draft-ietf-sip-rfc2543bis-02
> 
> 
> In table 4 and 5 of draft-ietf-sip-rfc2543bis-02, the OPTIONS 
> message cannot have the "Expires" or the "Priority" headers.
> 
> Couldn't the "Expires" header be used to *check* if a call 
> can be established using OPTIONS, within the specified time?

THis is not the meaning of expires. As a general header, it refers to the
amount of time for which the request is valid. That is not the same thing as
the amount of time over which a call from the same party would be
acceptable.


> 
> Similarly, couldn't "Priority" be used to *check* if a call 
> will succeed through a heavily-laden proxy that uses 
> "Priority" to filter out calls (to reduce the load)? It is 
> true that even sending an OPTIONS will un-necessarily 
> increase the load on the proxy.

I doubt this is useful in any case. By the time you send your INVITE, the
state of the proxy or UA might have changed so that the resulting decision
would be different in any case.

> 
> Regarding the bug in draft-ietf-sip-rfc2543bis-02, I think 
> "6.46 User-Agent" is supposed to refer to H14.43 and not 
> "H14.42" as mentioned.

We've gotten many such notes along these lines. RFC2543 references the older
http spec, and most of those references are now incorrect in rfc2617. We
will need to do a global sweep through the document and check all of them.

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 01:00:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23167
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 01:00:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7544D4437D; Tue, 16 Jan 2001 00:01:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id DA3D54437B
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 00:00:02 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA13361;
	Tue, 16 Jan 2001 00:56:34 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KH74V>; Tue, 16 Jan 2001 00:50:37 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB0D0@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Divya  Nath'" <divyanath@rediffmail.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Proxy and Redirect Servers
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 00:50:31 -0500



 

> -----Original Message-----
> From: Divya Nath [mailto:divyanath@rediffmail.com]
> Sent: Tuesday, January 09, 2001 7:21 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Proxy and Redirect Servers
> 
> 
> Hi ,
>      In section 4.2 of the internet draft 
> ietf-sip-rfc2543-bis-0.2ps the following is written 
> 
> "Proxy and redirect servers treat all methods other than 
> INVITE and CANCEL in the same way, by forwarding them accordingly"
> 
> Can anybody clearify how proxy and redirect servers treat all 
> other methods in the same way?

THe primary job of a proxy and a redirect server is message routing. That
is, they receive a request, look at the request URI, and then based on some
logic, figure out the next hop SIP URL, and then forward (or redirect) the
request there. What this sentence is trying to say is that this processing
is method independent. A proxy routing should be done identically for
INVITE, OPTIONS, and FOOBAR.

The text is a bit confusing since:

1. ACK treatment is also different; ACK and CANCEL are almost always special
as they are associated with another transaction
2. Its really just the routing for which proxy and redirect servers treat
all methods the same way. A proxy will treat OPTIONS and INVITE in different
ways from a retransmission and reliability perspective.

-Jonathan R.


---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 01:02:34 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23187
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 01:02:34 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D034244383; Tue, 16 Jan 2001 00:01:10 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 2EA0C4437B
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 00:00:07 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA13385;
	Tue, 16 Jan 2001 01:02:44 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KH746>; Tue, 16 Jan 2001 00:56:47 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB0D1@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Christer Holmberg'" <christer.holmberg@lmf.ericsson.se>,
        sip@lists.bell-labs.com
Subject: RE: [SIP] Mix or replace
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 00:56:45 -0500



 

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@lmf.ericsson.se]
> Sent: Tuesday, January 09, 2001 3:46 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Mix or replace
> 
> 
> 
> Hi,
> 
> This issue was mentioned in, and is part of, the early media 
> replacement
> thread, but I would like to ask about here.
> 
> My question is: If we receive multiple 183 responses, with SDP message
> bodies, from different locations, should we:
> 
> 1. Mix the media streams
> 
> ...or...
> 
> 2. Replace the media stream every time we get a new 183 response.
> 
> My assumption was option 2, but since Jonathan mentioned the audio
> mixing in a previous mail I would like to raise the question.
> 
> The problem is that there be cases where one option is to be 
> used, while
> in other cases the option is to be used...

I don't think this needs to be specified. If I'm in multiple calls, the spec
does not say whether I need to play just one of the media streams at a time,
or mix them and play both. Its a local decision based on the end device.

In the case of early media, I can imagine a smart phone that creates new
call apperances as it gets multiple 183s (each will have different tags),
allowing me to select which appearance I listen to (note that there is a
problem in figuring out which media stream is associated with each call
appearance, unless we have some kind of rtcp SDES item that conveys the SIP
URL, or define an sdp attribute for ssrc or cname). Another phone might
always play just one and ignore all the others. Yet another might mix them,
although I suspect that is not what you will want in most cases.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 01:05:13 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23254
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 01:05:13 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6C8D044388; Tue, 16 Jan 2001 00:03:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 736AB44382
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 00:02:48 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA13402;
	Tue, 16 Jan 2001 01:05:24 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KH740>; Tue, 16 Jan 2001 00:59:27 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB0D2@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Mayank Sharma'" <mayanks@mindtree.com>,
        SIP discussion list <sip@lists.bell-labs.com>
Subject: RE: [SIP] Regarding Multiple Content Types
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 00:59:17 -0500



 

> -----Original Message-----
> From: Mayank Sharma [mailto:mayanks@mindtree.com]
> Sent: Wednesday, January 10, 2001 1:03 AM
> To: SIP discussion list
> Subject: [SIP] Regarding Multiple Content Types
> 
> 
> Hi List,
> 	I have a question about sending a Message body with a
> Request/Response. Can I send a Message body with more than 
> one Content Type..

Yes. You would use MIME multipart. See rfc2045.


-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 01:14:29 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24404
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 01:14:29 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BC51644339; Tue, 16 Jan 2001 00:12:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 4C28044336
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 00:11:17 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA13474;
	Tue, 16 Jan 2001 01:13:54 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KH7VS>; Tue, 16 Jan 2001 01:07:57 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB0D3@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'laks hmi'" <lakshmiam@yahoo.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Regarding SIP-URL
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 01:07:46 -0500

No, telephone-subscriber cannot have quotes. Quotes are not valid uri
characters according to rfc2396.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

> -----Original Message-----
> From: laks hmi [mailto:lakshmiam@yahoo.com]
> Sent: Wednesday, January 10, 2001 4:26 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Regarding SIP-URL
> 
> 
> Hi,
> 
> In rfc, they have told to exclude the delimiters used
> for Request-URI inside . But in the authorize and
> authenticate headers, SIP-URL is coming in cotes, but
> cotes is also coming in the telphone-subscirber. 
> 
> pl clarify this.
> 
> lakshmi
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Photos - Share your holiday photos online!
> http://photos.yahoo.com/
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 01:20:10 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25192
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 01:20:10 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7CB714437A; Tue, 16 Jan 2001 00:14:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 2A3FD44336
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 00:13:06 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA13488;
	Tue, 16 Jan 2001 01:15:44 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KH7VV>; Tue, 16 Jan 2001 01:09:47 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB0D4@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Gaurav Taneja'" <A15835@email.mot.com>,
        SIP WG Mailing List <sip@lists.bell-labs.com>
Cc: Gaurav <Gaurav_Taneja-A15835@email.mot.com>
Subject: RE: [SIP] RFC 2543 - SIP Protocol Properties
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 01:09:40 -0500



 

> -----Original Message-----
> From: Gaurav Taneja [mailto:A15835@email.mot.com]
> Sent: Wednesday, January 10, 2001 9:12 AM
> To: SIP WG Mailing List
> Cc: Gaurav
> Subject: [SIP] RFC 2543 - SIP Protocol Properties
> 
> 
> Hi,
> 
> This is with reference to RFC 2543 (March 1999), page 19, 
> section 1.5.2
> "Lower-Layer-Protocol Neutral" . The last line in para. 2 states that
> "TCP allows easier passage through existing firewalls".  Could someone
> elaborate on how TCP supports this?
> 
> -Gaurav
> 

Its the other way around. TCP doesn't support firewalls, firewalls support
TCP. They often let TCP connections through, but almost never UDP.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 01:26:10 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25960
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 01:26:10 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 96F6544369; Tue, 16 Jan 2001 00:21:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id A7EF44439A
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 00:20:46 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA13528;
	Tue, 16 Jan 2001 01:23:24 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KH7V0>; Tue, 16 Jan 2001 01:17:27 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB0D6@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'mgovind@hss.hns.com'" <mgovind@hss.hns.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Tel-Url query
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 01:17:23 -0500



 

> -----Original Message-----
> From: mgovind@hss.hns.com [mailto:mgovind@hss.hns.com]
> Sent: Thursday, January 11, 2001 7:29 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Tel-Url query
> 
> 
> 
> 
> Hello,
> 
> I have a query regarding the usage of "Tel" URLs specified in
> the RFC 2806 as a part of the Addr-spec within the SIP Headers.
> The ABNF for the Tel URL includes
> 
> token-char = (%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
>                 / %x41-5A / %x5E-7A / %x7C / %x7E)
>                *(%x21-3A / %x3C-7E)
> 
> which is a part of "private-prefix". These characters include
> "<", ">" among others.

Thats probably a mistake.

> 
> Do these particular characters need to be escaped if the URL
> appears as a part of the Addr-spec within a SIP header, like 'From'?

THey need to be escaped, period. The "<" and ">" are not valid URI
characters according to rfc2396. This specification defines syntax for all
URIs, including SIP and tel.

-Jonathan R.



---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 01:32:08 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26832
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 01:32:08 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 478F844391; Tue, 16 Jan 2001 00:26:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id B34B344339
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 00:25:16 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA13559;
	Tue, 16 Jan 2001 01:27:44 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KH7WH>; Tue, 16 Jan 2001 01:21:47 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB0D7@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Aymeric Moizard'" <aymeric.moizard@matranortel.com>,
        sip@lists.bell-labs.com
Subject: RE: [SIP] Question on draft-ietf-sip-100rel-02.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 01:21:45 -0500



 

> -----Original Message-----
> From: Aymeric Moizard [mailto:aymeric.moizard@matranortel.com]
> Sent: Thursday, January 11, 2001 11:10 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Question on draft-ietf-sip-100rel-02.txt
> 
> 
> 
> Hi,
> 
> The draft-ietf-sip-100rel-02.txt appears to
> expire in December 2000. Is there a new
> version of this one and is it on the way
> to be accepted?

This document was submitted to IESG for consideration
as proposed standard. According to:

http://www.ietf.org/IESG/status.html

it has been under AD review since September 8.


> 
> How do we cancel the INVITE if the UAC has
> already received the 183 response. Must we
> complete the PRACK "transaction" and send
> "request canceled" for invite right after?

Cancellation of the INVITE would proceed normally. You'd send a CANCEL, and
the UAS would respond with a 487 to the INVITE, and then a 200 OK to the
CANCEL. Any reliable provisionals in progress would complete normally; that
is, the UAS would continue to retransmit them until it received a PRACK.
This is part of the important SIP characteristic that all transactions
complete normally and independently of any other transactions.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 01:38:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27672
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 01:38:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4583C44395; Tue, 16 Jan 2001 00:38:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id B3B1A44387
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 00:37:51 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA13636;
	Tue, 16 Jan 2001 01:40:25 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KH7W5>; Tue, 16 Jan 2001 01:34:28 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB0D8@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Rick Dean'" <siplist@fdd.com>
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Early media replacement.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 01:34:26 -0500



 

> -----Original Message-----
> From: Rick Dean [mailto:siplist@fdd.com]
> Sent: Tuesday, January 09, 2001 11:20 AM
> To: Jonathan Rosenberg
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] Early media replacement.
> 
> 
> On Tue, Jan 09, 2001 at 01:25:41AM -0500, Jonathan Rosenberg wrote:
> > In practice, I doubt calls to PSTN numbers will fork anyway. 
> 
> Then why do you oppose me?  

Because I do not believe forking is the only aspect of this issue.
> 
> PSTN interoperability is paramount to me.  
> Unfortunately, my calls need to work better 
> than 99% of the time.  
> 
> If gateways "need to send media 
> in the reverse direction without knowing what 
> it is", then they should send a 200 OK because
> the forking won't work anyway.  Why else
> should early media persist if not for
> forking? 

Because always sending a 200 OK has implications
for services on the SIP side. For example, it completely
eliminates the possibility of a call forward busy or 
call forward no answer. This is the reason why the two
phase INVITE in the original DCS proposal was so disliked - 
it changed the fundamental notion of what sending a 200 OK
meant. 

>  Hopefully, the gateway builders will 
> do the right thing.

Its not a question of lazy implementations. Its a question of not having
enough
information to send anything but early media.

> Let's depreciate early media.

Lets stop making broad, sweeping statements about the directions to go in,
and rather analyze the problem so we can arrive at a proper conclusion.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 01:43:33 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28151
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 01:43:32 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8CA16443A4; Tue, 16 Jan 2001 00:41:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id A89F544395
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 00:40:17 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA13664;
	Tue, 16 Jan 2001 01:42:54 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KH7XB>; Tue, 16 Jan 2001 01:36:57 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB0D9@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Grant McSheffrey'" <grant.mcsheffrey@empowertel.com>,
        Sip List <sip@lists.bell-labs.com>
Subject: RE: [SIP] Timestamp header
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 01:36:53 -0500

The spec is not clear on this, saying simply that it should be echoed. I
would imagine placing it in all responses, provisional and final, makes the
most sense.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

> -----Original Message-----
> From: Grant McSheffrey [mailto:grant.mcsheffrey@empowertel.com]
> Sent: Thursday, January 11, 2001 11:42 AM
> To: Sip List
> Subject: [SIP] Timestamp header
> 
> 
> If a client sends an INVITE request containing a Timestamp header,
> should the Timestamp be echoed back in both provisional responses and
> the final response, or should it only appear in the first provisional
> response that is sent?
> 
> It seems to make sense that since it used to calculate timing, it is
> only needed in the first response but I have a developer who seems to
> think differently.
> 
> Any help greatly appreciated.
> 
> Grant McSheffrey
> Test Engineer
> EmpowerTel Networks
> 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 01:57:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29851
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 01:57:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5ABC844379; Tue, 16 Jan 2001 00:58:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lists.bell-labs.com (Postfix) with ESMTP id 56CDB44339
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 00:57:53 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f0G6veC26163
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 07:57:40 +0100 (MET)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.38])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id IAA04807
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 08:57:39 +0200 (EET)
Message-ID: <3A63F0E3.459BA9E7@lmf.ericsson.se>
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: multipart/mixed;
 boundary="------------26D8CC28FC1DD8BB5DAFF462"
Subject: [SIP] Media after INVITE
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 08:57:39 +0200

This is a multi-part message in MIME format.
--------------26D8CC28FC1DD8BB5DAFF462
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

I was reading the thread about Early media replacement. My question,
however, has not so much to do with the 183-to-be-or-not-to-be, but
rather with the requirement that a UA should be able to receive media
after the first INVITE is sent. This mean that the remote user wouldn't
have to send any response at all - instead he could start sending media
and would never be charged for it. Yes, the re-transmission timer for
the INVITE will expire, and the call will be dropped, but until that the
remote party have plenty of time to send media to the caller (even if
it's only one-way, it can be a news service/weather service/ voice mail/
whatever, where two-way direction is not needed).

My opinion is that SOME response (183, 200, or whatever will be decided
upon) should be received before the UA is required to start receiving
media. I know that we then can get some other issues, ie. if it takes a
long time for the 200 response to reach the caller the first RTP media
packets will be lost. But, again, at least the caller (or a possible
intermediate proxy handling charging) will know that the media can be
sent.

This doesn't solve the issue about getting media streams from different
locations, but at least we would know when we should expect to receive
media in the first place.

This issue may have been discussed before, so I appologise if I'm
bringing it up again...

Regards,

Christer Holmberg
Ericsson Finland
--------------26D8CC28FC1DD8BB5DAFF462
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------26D8CC28FC1DD8BB5DAFF462--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 02:00:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01284
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 02:00:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 627BA4438F; Tue, 16 Jan 2001 00:59:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 38ABD44339
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 00:58:36 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA13747;
	Tue, 16 Jan 2001 01:53:35 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KH7XW>; Tue, 16 Jan 2001 01:47:38 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB0DA@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Christian Huitema'" <huitema@exchange.microsoft.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        Michael Thomas <mat@cisco.com>
Cc: Henning Schulzrinne <hgs@cs.columbia.edu>, sip@lists.bell-labs.com
Subject: RE: [SIP] new record-route text!
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 01:47:30 -0500



 

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@exchange.microsoft.com]
> Sent: Tuesday, January 09, 2001 11:37 AM
> To: Jonathan Rosenberg; Michael Thomas
> Cc: Henning Schulzrinne; sip@lists.bell-labs.com
> Subject: RE: [SIP] new record-route text!
> 
> I would not object all that much if the specification did not preclude
> bypass of the recorded route, e.g. by issuing a re-invite to the 
> contact address through an entirely new path. This would allow the
> conversation to be redirected to a more direct path, or to a path
> that is less dependent of the initial set of proxies. Come to 
> think of 
> it, there is no way to prevent UAs to do just that, which 
> means that we
> should not specify the impossible.

Well, the SIP spec is full of MUSTs, almost all of which are things that you
cannot prevent a UA or proxy from doing. That doesn't mean they shouldn't be
a MUST. Things are a MUST when not doing them will normally cause protocol
operations to fail. I think that will be the case here. The new text already
is very explicit about proxies not record routing gratiutiously. WHen they
do it, it is almost always since its in the best interests of the user -
either the signaling won't work at all, or some features are provided that
won't work. The user has no way of knowing, and so the only sensible thing
is to honor the record route, since it really is in the user's best interest
to do so.

Mike Thomas writes:
>  > Record route serves many useful functions; functions that
>  > user agents will want to get from proxy servers. They are critical
>  > for call features (such as those provided by sip cgi, cpl, 
> servlets, etc.),
>  > security functions of all sorts, including but not limited 
> to firewall
>  > traversal,
> 
>    I'm not sure what you mean by security functions. As
>    I posted earlier, if you mean things that require the
>    proxy to open and close something that doesn't actually
>    pass through it (like, say, media) you already have to
>    deal with soft-state elsewhere. At the least, record 
>    route is adding extra hops that soft-state could 
>    probably reap, and at worst, it might be (perhaps
>    mistakenly) adding soft state to your proxy as well.

There are other security functions besides firewall traversal. For example,
a VoIP provider will probably want to have a bunch of access proxies which
authenticate the users and/or calls at the ingress to the network. Once
authenticated at the edge, the messages are allowed to pass into the
network, and once inside, are not re-authenticated by all proxies within the
domain. In such a scenario, the access proxies will need to record route in
order to validate each message. 

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 02:04:07 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05574
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 02:04:06 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9F545443A3; Tue, 16 Jan 2001 01:02:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id CFCF944379
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 01:01:57 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA13882;
	Tue, 16 Jan 2001 02:04:35 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KH7YW>; Tue, 16 Jan 2001 01:58:38 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB0DC@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Ngo, Dai'" <c-Dai.Ngo@WCOM.Com>,
        "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
Subject: RE: [SIP] Request-Contact Header
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 01:58:34 -0500


  
-----Original Message-----
>From: Ngo, Dai [mailto:c-Dai.Ngo@WCOM.Com]
>Sent: Friday, January 12, 2001 4:32 PM
>To: 'sip@lists.bell-labs.com'
>Subject: [SIP] Request-Contact Header
>
>
>
>
>I recently ran across this question after looking at the IETF
draft-mahy-sip-message-
>waiting-00.txt:
>Where is the Request-Contact header documented?
>Thanks.
>-- Dai Ngo 

This is an error in the document. The text really means to say
Accept-Contact, which is defined in the caller preferences specification:

http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-03.txt

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 02:08:36 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06731
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 02:08:35 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DA6BD44396; Tue, 16 Jan 2001 01:04:12 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 17FE0443AC
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 01:03:21 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA13780;
	Tue, 16 Jan 2001 01:58:25 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KH7X9>; Tue, 16 Jan 2001 01:52:28 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB0DB@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Itamar Gilad'" <ItamarG@tlv.radvision.com>,
        "'Sekhar Banerjee'" <SBanerjee@lboard.com>,
        SIP List <sip@lists.bell-labs.com>
Subject: RE: [SIP] Issue with BYE
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 01:52:23 -0500



 

> -----Original Message-----
> From: Itamar Gilad [mailto:ItamarG@tlv.radvision.com]
> Sent: Monday, January 15, 2001 10:10 AM
> To: 'Sekhar Banerjee'; SIP List
> Subject: RE: [SIP] Issue with BYE
> 
> 
> When C accepted the call it sent a Contact header in the 2xx 
> response (this
> is a MUST in bis-02). The Contact is "indicating the SIP 
> address under which
> it is reachable most directly" (2.6).

Correct. The caller preferences spec also allows that Contact header to have
some parameters to tell you characteristics of the device. For example:

SIP/2.0 200 OK
Contact: sip:jdrosen-vmail@myhost.dynamicsoft.com;feature="voice-mail"

would tell you that you've contacted a voice mail server.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
> 
>   Itamar
> 
> > -----Original Message-----
> > From: Sekhar Banerjee [mailto:SBanerjee@lboard.com]
> > Sent: Sat, January 13, 2001 3:10 AM
> > To: SIP List
> > Subject: [SIP] Issue with BYE
> > 
> > 
> > Hi All,
> > 	I have a wierd issue that I am facing in my call flows. 
> > While trying
> > to implement call forwarding I have come across a particular 
> > case which I
> > would like the experts to look at. 
> > 	
> > 	If phone A is trying to call phone B which has been forwarded to
> > phone C. When C hangs up the BYE from C to A doesnt have 
> > anything in the
> > message that would indicate that the message has come from 
> > phone C. Is there
> > any way in which we cna figure out where the message is 
> > comming from by
> > looking at the message ?
> > 
> > Thanks
> > 
> > Sekhar
> > 
> > 
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> > 
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 02:12:59 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06786
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 02:12:59 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 637B144397; Tue, 16 Jan 2001 01:13:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 3975544368
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 01:12:42 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA13991;
	Tue, 16 Jan 2001 02:15:07 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KH7ZS>; Tue, 16 Jan 2001 02:09:09 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB0DD@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Rolland, Frederic'" <Frederic.Rolland@Compaq.com>,
        "'???'" <hslee@miptel.com>
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] [SIP]How do the proxy server search the next proxy serv
	 er ?
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 02:09:03 -0500



 

> -----Original Message-----
> From: Rolland, Frederic [mailto:Frederic.Rolland@Compaq.com]
> Sent: Friday, January 12, 2001 11:25 AM
> To: '???'
> Cc: sip@lists.bell-labs.com
> Subject: RE: [SIP] [SIP]How do the proxy server search the 
> next proxy serv er ?
> 
> 
> Hello!
> I think there are 3 differents URIs that can be used...
> * Since "UAc" wants to contact UAs "dragon" registered at 
> "bbb.com" domain,
> requested URI would normally be "sip:dragon@bbb.com"... (no 
> host address,

That is correct. Users will not normally know the host names of the machines
that they want to call; all they have is a machine independent identifier
(exactly like the email address), which is translated and routed to the
called party's machine.

> just domain identifier, then "sip.bbb.com" must locate "dragon" user)
> In this case, "sip.aaa.com" proxy has simply to place DNS 
> requests for a
> relevant SIP service handler at "bbb.com", that is 
> "sip.bbb.com", to get
> the proper address and so the route to it..

Thats not quite right. THe actual DNS query (see
http://www.normos.org/ietf/rfc/rfc2782.txt) would be for:

_sip._udp.bbb.com



> 
> * If "UAc" knows current static host address mapping for UAs 
> "dragon", like
> "dragon.bbb.com" (host address, this time), or if no location 
> service is
> used at "sip.bbb.com" (allowing proxy to locate the user's 
> current host)
> "UAc " must use dragon@dragon.bbb.com, but I'm not sure that 
> the session
> will go through "sip.bbb.com" this time...

If you know the host name of the machine where the user resides, you can
send it directly there, yes. It will, of course, not flow through proxies.
In most real scenarios you will not know the machine name.


-Jonathan R.

> -----Original Message-----
> From: hslee@miptel.com [ mailto:hslee@miptel.com 
<mailto:hslee@miptel.com> ]
Sent: Friday, January 12, 2001 11:27 AM
To: sip@lists.bell-labs.com
Subject: [SIP] [SIP]How do the proxy server search the next proxy server ?






proxy 1 : sip.aaa.com
proxy 2 : sip.bbb.com
UAc : arnold@arnold.aaa.com
UAs : dragon@dragon.bbb.com


1) When UAc sends a request(INVITE) to proxy 1, what is the Request-URI in
the Request-Line ?
    (a) INVITE : sip:dragon@sip.bbb.com
    (b) INVITE : sip:dragon@dragon.bbb.com
    Which is the correct answer ?

If (b) is right,
2) How do the proxy server 1 search the next proxy server 2?

Please, Could you correct me ?
Happy new year and have a good healthy!!!
  

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 02:32:07 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06863
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 02:32:07 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 68ED34438D; Tue, 16 Jan 2001 01:32:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb14.rediffmail.com (unknown [203.199.83.22])
	by lists.bell-labs.com (Postfix) with SMTP id 239E944387
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 01:31:55 -0500 (EST)
Received: (qmail 9464 invoked by uid 510); 16 Jan 2001 07:26:29 -0000
Message-ID: <20010116072629.9463.qmail@mailweb14.rediffmail.com>
Received: from unknown (203.197.174.37) by rediffmail.com via HTTP; 16 Jan 2001 07:26:29 -0000
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
From: "Vijeth  D" <vijethd@rediffmail.com>
Content-ID: <Tue_Jan_16_12_56_28_IST_2001_0@mailweb14.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Subject: [SIP] OPTIONS request
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 16 Jan 2001 07:26:29 -0000
Content-Transfer-Encoding: 7bit

Hi,
  If I am a UAS and i recieve an OPTIONS request on what basis do i decide whether or not to send a response? 
Should all OPTIONS requests be authenticated?

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 02:44:33 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06921
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 02:44:33 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 86ED2443A0; Tue, 16 Jan 2001 01:37:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb12.rediffmail.com (unknown [203.199.83.28])
	by lists.bell-labs.com (Postfix) with SMTP id DE4024438D
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 01:36:10 -0500 (EST)
Received: (qmail 26430 invoked by uid 510); 16 Jan 2001 07:28:22 -0000
Message-ID: <20010116072822.26429.qmail@mailweb12.rediffmail.com>
Received: from unknown (203.197.174.37) by rediffmail.com via HTTP; 16 Jan 2001 07:28:22 -0000
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
From: "Vijeth  D" <vijethd@rediffmail.com>
Content-ID: <Tue_Jan_16_12_58_22_IST_2001_0@mailweb12.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Subject: [SIP] REGISTER requests
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 16 Jan 2001 07:28:22 -0000
Content-Transfer-Encoding: 7bit

Hi,
  What does the REGISTRAR do after recieving a REGISTER request i.e, a valid request with user name password and the like? How will the REGISTRAR find the IP address corresponding to the SIPURL being registered and how does he update the Location server of the same?

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 05:37:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07761
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 05:37:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BA94144346; Tue, 16 Jan 2001 04:38:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 7D58A44343
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 04:37:00 -0500 (EST)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <CKD5P7BQ>; Tue, 16 Jan 2001 02:36:47 -0800
Message-ID: <E79883AEA37FD411A58C00508BAC5F4B2B5C73@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Keith Robinson'" <Keith.Robinson@marconi.com>
Cc: sip@lists.bell-labs.com, Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Subject: Outbound Proxies Renewed (was [SIP] Proxy Routing Logic)
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C07FA8.3679A930"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 02:36:41 -0800

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_01C07FA8.3679A930
Content-Type: text/plain;
	charset="iso-8859-1"

Trying to revive a stale unresolved thread ...

Keith Robinson wrote a very good synopsis of the problems but I disagree
with the conclusions drawn.

I would also like to reiterate Jonathan's design goals for a solutions: that
a proxy should not need to know whether it is being used as an outbound
proxy or have to take special action when being used as a outbound proxy.
The UA should be responsible for taking any action required (given that the
UA is the only entity that knows whether it using a proxy as an "outbound
proxy").

We seem to have two cases on the UA side:
1)	Does not have "Outbound Proxy" configured _or_ only needs to use
outbound proxy for SIP routing of initial request in a Call Leg.
2)	Needs to use outbound proxy for all SIP messages because it lacks
some ability. Eg DNS.

And we seem to have three cases on the proxy side. The proxy is
(unknowlingly) acting as a
1)	Normal proxy for UA, may or may not Record-Route.
2)	Outbound proxy for UA, no Record-Route needed [eg outbound proxy
only used for routing initial request]
3)	Outbound proxy for UA, needs to Record-route [eg. Firewall-like
proxy that must be used for all requests]

I am a proponent of Keith second course of action, that is, the UA does
_not_ strip the Route if it cannot use it (ie, UA case 2). [And Jonathan's
original suggestion]. However, I have a slight key modification! If the UA
sends a message without using the first Route header (assuming one exists),
then the request-URI is set to the outbound proxy's address !! eg
sip:proxy_address

Let me first say that I am not in favor of using Record-Routes of the form
Record-Route: original_request_uri;maddr=proxy_address. 
Under the new record-route rules this should not be required. The "problem"
that Keith poses is a good example of why this form of record route is bad.
Whenever a Route header of this form is used, the maddr is often dropped. A
proxy that sees the request has no way of knowing whether the Request-URI is
due to a Route header that the proxy added itself (or not). In the first
case proxy should use the next route; otherwise I believe it should merely
forward the request to the Request-URI as written.

In my mind, it is this problem that causes the difficulties that are being
experienced. 

The only problematic situation of all the above outbound proxy UA/proxy
permutations is when the proxy record routes _and_ the UA does not remove
the record route. (Proxy case 3 & UA case 2). So the first Route entry is
actually the Route header added by the outbound proxy- but now the
Request-URI will be equal to the proxy's address.

A proxy should not gobble/use the next Route header unless the Request-URI
specifies the proxy itself, right?  So it makes sense that when the proxy is
(unknowingly) acting as an outbound proxy _and_ the first record-routed
proxy that you might have to route/process a message twice (logically). The
UA inserted request-uri ensures that the message is routed to the outbound
proxy and that the proxy is able to use the next Route entry.

I don't see it as a problem that the proxy receives a request (to which it
is the target) and also finds itself in the first Route - it shouldn't break
things. Spiral routes included. The proxies need to differentiate multiple
Record-Routes for spiral routes in any case !! The first proxy should see
itself as the target of the Request-URI (due to UA's actions) which allows
the proxy to process the next Route header. Finding yourself as the next
recipient should not break things - its possible for this to occur with
spiral routes in any case, right?
 
This topic brings many of the currently contentious SIP issues out into the
open: Record-Route mechanism, maddr problems, transparent proxies and of
course outbound proxies. I'm sure many people will disagree but I thought I
would at least throw another cat among the pigeons.

Regards,

Robert.

-- My opinions are my own and should not be taken as representing those of
Nuera Communications, Inc. --

		-----Original Message-----
		From:	Keith Robinson [mailto:Keith.Robinson@marconi.com]
		Sent:	Thursday, January 04, 2001 3:42 AM
		To:	Jacek_Grabiec@3com.com
		Cc:	sip@lists.bell-labs.com; billy@billybiggs.com;
hgs@cs.columbia.edu; Jonathan Rosenberg; rfairlie@nuera.com;
jhornsby@ubiquity.net; vkg@lucent.com
		Subject:	RE: [SIP] Proxy Routing Logic



		The main conflict appears to be when a call stateful proxy,
which is acting as
		an outbound proxy for some UAs, record routes.
		The question for subsequent requests is who does the popping
of the first ROUTE
		entry into the R-URI ?

		For the UA, the two cases are :

		a) The UA pops the first route entry into the R-URI and
sends to its outbound
		proxy

		or

		b) The UA sends the request directly to its outbound proxy
without modifying the
		Route header and using, say, the URI in TO field as the
R-URI

		For case (a) the proxy (serving sipnet.com)  will see
something like the
		following
		(Assume the original request was addressed to
user1@anothernet.com)

		INVITE sip:user1@anothernet.com;maddr=proxy.sipnet.com

		the Route header may or may not be empty dependant on
whether further
		downstream proxies have record routed.

		For case (b) the proxy will receive something like

		INVITE sip:user1@anothernet.com
		Route: <sip:user1@anothernet.com;maddr=proxy.sipnet.com>

		Now,  for case (a), the request will be routed internally to
the appropriate
		call state machine
		using the R-URI, To, From and Call-Id headers. The request
will be processed and
		routed to the next server
		using information obtained from the original INVITE lookup,
stored CONTACT or
		the ROUTE header
		if present.

		For case (b) the request will be routed internally to the
appropriate call state
		machine as for
		case (a). The request will be processed and routed to the
next server using the
		ROUTE header
		which will send it back to the this proxy, identifying the
same call state
		machine as before; at best
		this will cause the request to be processed twice, at worst
it could cause
		problems with state,
		duplication of output etc,. The situation could be even
worse if the proxy uses
		rr-params to store state
		information to be returned in the R-URI, perhaps for
identifying spiralled call
		state machines.
		To stop this from happening, the proxy would have to perform
some look ahead
		processing on the
		Route header before deciding whether or not to actually use
the next Route
		entry, or merely
		remove it; this is special case processing on the usage of
the Route header and
		could become problematic if the proxy appears more than once
in the Route list
		due
		to spiralling.


		I therefore think that the UA should function as in case (a)
to eliminate the
		problems associated with
		case (b).

		Now, consider what happens when a UA operating as in case
(a) sends a subsequent
		request to
		its outbound proxy BUT the outbound proxy has deliberately
NOT record routed
		because it is not
		required to keep call state; however, two further downstream
proxies, serving
		nextsipnet.com and
		furthersipnet.com, HAVE record routed.

		The UA will have constructed a ROUTE header that looks
something like:

		Route: <sip:user2@nextsipnet.com;maddr=proxy.nextsipnet.com>
		Route:
<sip:user3@furthersipnet.com;maddr=proxy.furthersipnet.com>

		When the UA sends a subsequent INVITE, because it functions
as in case (a)
		it will pop the first Route entry into the R-URI, and send
this to its outbound
		proxy
		as it can't resolve proxy.nextsipnet.com because it has no
DNS capability.

		The proxy will receive the following :

		INVITE sip:user2@nextsipnet.com;maddr=proxy.nextsipnet.com
		Route:
<sip:user3@furthersipnet.com;maddr=proxy.furthersipnet.com>

		And this is the central point of the debate; should the
proxy route the above
		request by popping the first route entry into the R-URI, or
should it use
		the maddr in the R-URI received. In this case, the proxy
should clearly
		route the request using the maddr in the received R-URI,
otherwise
		proxy.nextsipnet.com will be bypassed even though it asked
to be kept
		in the path; this does, however, represent special case
processing dependant
		on the contents of the maddr.

		If the UA had functioned as in case (b) for the above
situation, then the proxy
		would need to route using the Route header.

		So, special case processing at the proxy appears unavoidable
no matter
		whether the UA functions as in case (a) or case (b), and
whether a proxy that is
		being used as an outbound proxy has record routed or not. I
think the question
		has
		to be is what special case processing is preferable and what
are  UA mandated to
		do with the Route header if they wish to use an outbound
proxy for subsequent
		requests.

		IMO, UAs using an outbound proxy should function as in case
(a) and proxies
		should look at the value of the received maddr before
deciding whether or not
		to route using the Route header if available. This provides
for the simplest
		rules; requiring the proxy to look at the entries in the
Route header before
		deciding
		if it can use the first entry (situation arising through
case (b) ) seems much
		more complex
		and prone to error.

		The text in 6.34.3 is unclear as to what a UA must do if it
is using an outbound
		proxy; I think
		it will lead to some UA functioning as in case (a) and some
as in case (b) which
		is the
		worst scenario as it becomes almost impossible for proxies
to know which
		processing
		to apply.

		Also, considering the above and continuing my previous point
on this thread
		about
		a roaming UA wishing to route through the context of its
home domain proxy I
		have the following in mind.

		A UA at visitednet.com has been given proxy.visited.net as
its local outbound
		proxy.
		The UA wishes to set up a call through its home domain proxy
to
		friend@anothernet.com.
		The UA may well construct a Route header to get to
proxy.homenet.com which looks
		like:

		Route <sip:friend@anothernet.com;maddr=proxy.homenet.com>

		Now, a UA that functions as in case (a) will send the
following to
		proxy.visitednet.com

		INVITE sip:friend@anothernet.com;maddr=proxy.homenet.com

		The Route header will be empty, as the UA has already popped
the entry
		into the R-URI.

		Upon receiving this request, proxy.visitednet.com (which
assumes all UA do case
		(a) )
		will see that the maddr refererences a domain not served by
itself and so
		forward the
		request to proxy.homenet.com, which will see the request:

		INVITE sip:friend@anothernet.com;maddr=proxy.homenet.com

		which is Billy's very first example on this thread.

		In this case I would want proxy.homenet.com to now route
using the URI
		friend@anothernet.com, which was my original point.

		If the UA functions as in case (b) then proxy.visitednet.com
(which assumes all
		UA do case (b) )
		receives

		INVITE sip:friend@anothernet.com
		Route: <sip:friend@anothernet.com;maddr=proxy.homenet.com>

		proxy.visitednet.com then pops the first Route entry into
the R-URI and forwards
		to proxy.homenet.com
		which receives the following

		INVITE sip:friend@anothernet.com;maddr=proxy.homenet.com

		which is exactly the same as if the UA/proxy were
functioning as in case (a).

		So, to summarise, assuming UAs function as in case (a), if a
proxy receives a
		R-URI
		with an maddr that does not reference the domain the proxy
serves then the proxy
		sends the request to that maddr, regardless of the Route
headers; if a proxy
		receives
		a R-URI with an maddr that does reference the domain it
serves then it strips
		the maddr
		and goes through the normal routing procedures. The only
special case processing
		is
		the result of checking the maddr.

		Regards,

		K. Robinson.




















		Jacek_Grabiec@3com.com on 02/01/2001 15:07:13
	

	

	



	

	

	

		 To:      sip@lists.bell-labs.com

	

		 cc:      billy@billybiggs.com, hgs@cs.columbia.edu,
Jonathan 
		          Rosenberg <jdrosen@dynamicsoft.com>,

		          rfairlie@nuera.com, jhornsby@ubiquity.net,

		          vkg@lucent.com(bcc: Keith Robinson/MAIN/MC1)

	

	

	

		 Subject: RE: [SIP] Proxy Routing Logic

	










		Jonathan Rosenberg wrote;
		>To comment on the primary issue, ignoring the Route header
if the request
		>URI domain is not your own, and sending it to that domain
first, is
		>dangerous, IMHO. Thats because, nearly as I can tell, it
completely breaks
		>the existing usage of record-routing. In the existing
usage, a proxy copies
		>the request URI in the request into the record-route, and
adds its own
		>maddr. Requests in the reverse direction will only get
routed correctly
		>through that same set of proxies IFF each proxy uses the
top route header no
		>matter what. If proxies start to only sometimes use them,
we will end up
		>with incorrectly routed requests.

		I'm not sure if 'ignoring the Route header if the request
		URI domain is not your own, and sending it to that domain
first' breaks
		anything.
		I can see it may add another proxy to the path, but at least
all record-routed
		Proxies are on the path as well. Doing otherwise will break
routing (I gave an
		example
		in one of my previuos postings). I would argue that proxy
cannot blindly follow
		logic 'replace RURI with Route' no matter what just like it
does not proxy
		responses
		downstream if top-via doesn't match the server - it checks
if it matches first.

		>So, I would modify my proposal to satisfy some of the other
requirements:

		>1. If there is a Route header in a request, that ALWAYS
takes priority for
		>routing the request.
		>2. If there is none, and the request URI has a domain NOT
matching that of
		>the server, but the address/domain in the maddr does, the
server forwards to
		>the domain in the userhost portion of the R-URI. If the
neither the maddr or
		>userhost have an ipaddress/domain matching the proxy, the
proxy sends the
		>request to the address in the maddr. Stripping of maddr is
optional.

		your 2 suggestion is really close what I would have in mind.
There's also
		another
		scenario: where Proxy receives a request with maddr where
neither maddr nor host
		portion of RURI matches the server.

		Let's say proxy at sip.company.com receives a requests like:

		sip:abc@someone-else.com;maddr=proxy.com
		.......
		Route:
<sip:123@yet-someone-else.com;maddr=yet-yet-someone-else.com>

		As Billy pointed out you, being the proxy, don't really want
to pop Route header
		 blindly. I would rather
		propose something along theses lines - it is really close to
your 2 case (it
		also takes care of scenario where
		Proxy has it's own outbound Proxy which may have its own
outbound Proxy etc - if
		 you were to pop Route at
		every hop the message would never get to the proper
Proxies):
		Investigate RURI first:
		1)   if maddr exist and it doesn't match your domain send
message to:
		     - address indicated in maddr and strip maddr.
		     - or, if outbound Proxy is used, to outbound Proxy and
preserve maddr
		     - or, return 488 if unwilling/unable to forward the
request (I explained my
		 reasoning for 488 in previous posting)
		2)   if maddr exist and it matches your domain strip maddr
and go to 3
		3)   if host part of RURI doesn't match your domain send
message to:
		     - address indicated in host part of RURI and preserve
existing RURI and
		Route(s),
		     - or, if outbound Proxy is used, to outbound Proxy and
preserve existing
		RURI and Route(s),
		4)   if host part of RURI does match your domain pop first
Route header and go
		back to 1
		     (now your RURI is whatever Route header contained).
		5)   if there's no Route header do whatever you want (get
contact from your
		     location/registrar server most likely) and go back to 1
(now RURI is
		whatever you got
		     from location/registrar server)


		regards, Jacek Grabiec
		sip:jacek_grabiec@sip.3com.com



		_______________________________________________
		SIP mailing list
		SIP@lists.bell-labs.com
		http://lists.bell-labs.com/mailman/listinfo/sip

		

------_=_NextPart_001_01C07FA8.3679A930
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Outbound Proxies Renewed (was [SIP] Proxy Routing Logic)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Trying to revive a stale unresolved =
thread ...</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Keith Robinson wrote a very good =
synopsis of the problems but I disagree with the conclusions =
drawn.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I would also like to reiterate =
Jonathan's design goals for a solutions: that a proxy should not need =
to know whether it is being used as an outbound proxy or have to take =
special action when being used as a outbound proxy. The UA should be =
responsible for taking any action required (given that the UA is the =
only entity that knows whether it using a proxy as an "outbound =
proxy").</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">We seem to have</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">two</FONT><FONT SIZE=3D2 FACE=3D"Arial"> =
cases</FONT><FONT SIZE=3D2 FACE=3D"Arial"> on the UA</FONT><FONT =
SIZE=3D2 FACE=3D"Arial"> side:</FONT>

<OL TYPE=3D1><LI><FONT SIZE=3D2 FACE=3D"Arial">Does not =
have</FONT><FONT SIZE=3D2 FACE=3D"Arial"></FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">"</FONT><FONT SIZE=3D2 FACE=3D"Arial">Outbound =
Proxy</FONT><FONT SIZE=3D2 FACE=3D"Arial">"</FONT><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT> <FONT SIZE=3D2 FACE=3D"Arial">configured =
_</FONT><I><FONT SIZE=3D2 FACE=3D"Arial">or</FONT></I><FONT SIZE=3D2 =
FACE=3D"Arial">_</FONT><FONT SIZE=3D2 FACE=3D"Arial"> only needs</FONT> =
<FONT SIZE=3D2 FACE=3D"Arial">to use</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">outbound proxy for SIP routing of initial =
request</FONT><FONT SIZE=3D2 FACE=3D"Arial"> in a Call Leg</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">.</FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Needs</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">to use</FONT> <FONT SIZE=3D2 FACE=3D"Arial">outbound =
proxy for all SIP</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">messages</FONT><FONT SIZE=3D2 FACE=3D"Arial"> because it =
lacks</FONT> <FONT SIZE=3D2 FACE=3D"Arial">some ability. Eg</FONT> =
<FONT SIZE=3D2 FACE=3D"Arial">DNS.</FONT></LI>
<BR>
</OL>
<P><FONT SIZE=3D2 FACE=3D"Arial">And w</FONT><FONT SIZE=3D2 =
FACE=3D"Arial">e seem to have three cases on the proxy side</FONT><FONT =
SIZE=3D2 FACE=3D"Arial">. The proxy is (unknowlingly) acting as =
a</FONT>

<OL TYPE=3D1><LI><FONT SIZE=3D2 FACE=3D"Arial">Normal proxy for UA, may =
or may not Record-Route.</FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Outbound proxy for UA, no =
Record-Route needed [eg outbound proxy only used for routing initial =
request]</FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">Outbound proxy for UA, needs to =
Record-route [eg. Firewall-like proxy that must be used for all =
requests]</FONT></LI>
<BR>
</OL>
<P><FONT SIZE=3D2 FACE=3D"Arial">I am a proponent of Keith second =
course of action, that is, the UA does</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">_</FONT><I><FONT SIZE=3D2 =
FACE=3D"Arial">not</FONT></I><FONT SIZE=3D2 =
FACE=3D"Arial">_</FONT><FONT SIZE=3D2 FACE=3D"Arial"> strip the Route =
if it cannot use it (ie, UA case 2). [And Jonathan's original =
suggestion]</FONT><FONT SIZE=3D2 FACE=3D"Arial">. However, I have a =
slight key modification! If the UA sends a message without using the =
first Route header (assuming one exists), then the request-URI is set =
to the outbound proxy's address !! eg sip:proxy_address</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Let me first say that I am not in =
favor of using Record-Routes of the form</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Record-Route:</FONT><I> <FONT =
SIZE=3D2 FACE=3D"Arial">original_request_uri</FONT></I><FONT SIZE=3D2 =
FACE=3D"Arial">;maddr=3D</FONT><I><FONT SIZE=3D2 =
FACE=3D"Arial">proxy_address</FONT></I><FONT SIZE=3D2 FACE=3D"Arial">. =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Under the new record-route rules this =
should not be required. The "problem" that Keith poses is a good =
example of why this form of record route is bad. Whenever a Route =
header of this form is used, the maddr is often dropped. A proxy that =
sees the request has no way of knowing whether the Request-URI is due =
to a Route header that the proxy added itself (or not). In the first =
case proxy should use the next route; otherwise I believe it should =
merely forward the request to the Request-URI as written.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In my mind, it is this problem that =
causes the difficulties that are being experienced. </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The only problematic situation of all =
the above outbound proxy UA/proxy permutations is when the proxy record =
routes _</FONT><I><FONT SIZE=3D2 FACE=3D"Arial">and</FONT></I><FONT =
SIZE=3D2 FACE=3D"Arial">_ the UA does not remove the record route. =
(Proxy case 3 &amp; UA case 2). So the first Route entry is actually =
the Route header added by the outbound proxy- but now the Request-URI =
will be equal to the proxy's address.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A proxy should not gobble/use the next =
Route header unless the Request-URI specifies the proxy itself, =
right?&nbsp; So it makes sense that when the proxy is (unknowingly) =
acting as an outbound proxy _and_ the first record-routed proxy that =
you might have to route/process a message twice (logically). The UA =
inserted request-uri ensures that the message is routed to the outbound =
proxy and that the proxy is able to use the next Route =
entry.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I don't see it as a problem that the =
proxy receives a request (to which it is the target) and also finds =
itself in the first Route - it shouldn't break things. Spiral routes =
included. The proxies need to differentiate multiple Record-Routes for =
spiral routes in any case !! The first proxy should see itself as the =
target of the Request-URI (due to UA's actions) which allows the proxy =
to process the next Route header. Finding yourself as the next =
recipient should not break things - its possible for this to occur with =
spiral routes in any case, right?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">This topic brings many of the =
currently contentious SIP issues out into the open: Record-Route =
mechanism, maddr problems, transparent proxies and of course outbound =
proxies. I'm sure many people will disagree but I thought I would at =
least throw another cat among the pigeons.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Robert.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- My opinions are my own and should =
not be taken as representing those of Nuera Communications, Inc. =
--</FONT>
</P>
<UL><UL>
<P><A NAME=3D"_MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original =
Message-----</FONT></A>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:&nbsp;&nbsp; Keith Robinson =
[<A =
HREF=3D"mailto:Keith.Robinson@marconi.com">mailto:Keith.Robinson@marconi=
.com</A>]</FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D2 FACE=3D"Arial">Thursday, January 04, 2001 3:42 AM</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">Jacek_Grabiec@3com.com</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">sip@lists.bell-labs.com; billy@billybiggs.com; =
hgs@cs.columbia.edu; Jonathan Rosenberg; rfairlie@nuera.com; =
jhornsby@ubiquity.net; vkg@lucent.com</FONT></P>

<P><B><FONT SIZE=3D2 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D2 FACE=3D"Arial">RE: [SIP] Proxy Routing Logic</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">The main conflict appears to be when a =
call stateful proxy, which is acting as</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">an outbound proxy for some UAs, =
record routes.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">The question for subsequent requests =
is who does the popping of the first ROUTE</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">entry into the R-URI ?</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">For the UA, the two cases are :</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">a) The UA pops the first route entry =
into the R-URI and sends to its outbound</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">proxy</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">or</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">b) The UA sends the request directly =
to its outbound proxy without modifying the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Route header and using, say, the URI =
in TO field as the R-URI</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">For case (a) the proxy (serving =
sipnet.com)&nbsp; will see something like the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">following</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(Assume the original request was =
addressed to user1@anothernet.com)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">INVITE =
sip:user1@anothernet.com;maddr=3Dproxy.sipnet.com</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">the Route header may or may not be =
empty dependant on whether further</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">downstream proxies have record =
routed.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">For case (b) the proxy will receive =
something like</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">INVITE sip:user1@anothernet.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Route: =
&lt;sip:user1@anothernet.com;maddr=3Dproxy.sipnet.com&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Now,&nbsp; for case (a), the request =
will be routed internally to the appropriate</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">call state machine</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">using the R-URI, To, From and Call-Id =
headers. The request will be processed and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">routed to the next server</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">using information obtained from the =
original INVITE lookup, stored CONTACT or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the ROUTE header</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">if present.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">For case (b) the request will be =
routed internally to the appropriate call state</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">machine as for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">case (a). The request will be =
processed and routed to the next server using the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">ROUTE header</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">which will send it back to the this =
proxy, identifying the same call state</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">machine as before; at best</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">this will cause the request to be =
processed twice, at worst it could cause</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">problems with state,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">duplication of output etc,. The =
situation could be even worse if the proxy uses</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">rr-params to store state</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">information to be returned in the =
R-URI, perhaps for identifying spiralled call</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">state machines.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To stop this from happening, the =
proxy would have to perform some look ahead</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">processing on the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Route header before deciding whether =
or not to actually use the next Route</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">entry, or merely</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">remove it; this is special case =
processing on the usage of the Route header and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">could become problematic if the proxy =
appears more than once in the Route list</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">due</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to spiralling.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">I therefore think that the UA should =
function as in case (a) to eliminate the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">problems associated with</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">case (b).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Now, consider what happens when a UA =
operating as in case (a) sends a subsequent</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">request to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">its outbound proxy BUT the outbound =
proxy has deliberately NOT record routed</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">because it is not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">required to keep call state; however, =
two further downstream proxies, serving</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">nextsipnet.com and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">furthersipnet.com, HAVE record =
routed.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The UA will have constructed a ROUTE =
header that looks something like:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Route: =
&lt;sip:user2@nextsipnet.com;maddr=3Dproxy.nextsipnet.com&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Route: =
&lt;sip:user3@furthersipnet.com;maddr=3Dproxy.furthersipnet.com&gt;</FON=
T>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">When the UA sends a subsequent INVITE, =
because it functions as in case (a)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">it will pop the first Route entry =
into the R-URI, and send this to its outbound</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">proxy</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">as it can't resolve =
proxy.nextsipnet.com because it has no DNS capability.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The proxy will receive the following =
:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">INVITE =
sip:user2@nextsipnet.com;maddr=3Dproxy.nextsipnet.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Route: =
&lt;sip:user3@furthersipnet.com;maddr=3Dproxy.furthersipnet.com&gt;</FON=
T>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">And this is the central point of the =
debate; should the proxy route the above</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">request by popping the first route =
entry into the R-URI, or should it use</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the maddr in the R-URI received. In =
this case, the proxy should clearly</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">route the request using the maddr in =
the received R-URI, otherwise</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">proxy.nextsipnet.com will be bypassed =
even though it asked to be kept</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in the path; this does, however, =
represent special case processing dependant</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">on the contents of the maddr.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If the UA had functioned as in case =
(b) for the above situation, then the proxy</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">would need to route using the Route =
header.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So, special case processing at the =
proxy appears unavoidable no matter</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">whether the UA functions as in case =
(a) or case (b), and whether a proxy that is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">being used as an outbound proxy has =
record routed or not. I think the question</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">has</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to be is what special case processing =
is preferable and what are&nbsp; UA mandated to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">do with the Route header if they wish =
to use an outbound proxy for subsequent</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">requests.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">IMO, UAs using an outbound proxy =
should function as in case (a) and proxies</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">should look at the value of the =
received maddr before deciding whether or not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to route using the Route header if =
available. This provides for the simplest</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">rules; requiring the proxy to look at =
the entries in the Route header before</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">deciding</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">if it can use the first entry =
(situation arising through case (b) ) seems much</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">more complex</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and prone to error.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The text in 6.34.3 is unclear as to =
what a UA must do if it is using an outbound</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">proxy; I think</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">it will lead to some UA functioning =
as in case (a) and some as in case (b) which</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">worst scenario as it becomes almost =
impossible for proxies to know which</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">processing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to apply.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Also, considering the above and =
continuing my previous point on this thread</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">about</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a roaming UA wishing to route through =
the context of its home domain proxy I</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">have the following in mind.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">A UA at visitednet.com has been given =
proxy.visited.net as its local outbound</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">proxy.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">The UA wishes to set up a call =
through its home domain proxy to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">friend@anothernet.com.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">The UA may well construct a Route =
header to get to proxy.homenet.com which looks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">like:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Route =
&lt;sip:friend@anothernet.com;maddr=3Dproxy.homenet.com&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Now, a UA that functions as in case =
(a) will send the following to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">proxy.visitednet.com</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">INVITE =
sip:friend@anothernet.com;maddr=3Dproxy.homenet.com</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The Route header will be empty, as the =
UA has already popped the entry</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">into the R-URI.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Upon receiving this request, =
proxy.visitednet.com (which assumes all UA do case</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(a) )</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">will see that the maddr refererences =
a domain not served by itself and so</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">forward the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">request to proxy.homenet.com, which =
will see the request:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">INVITE =
sip:friend@anothernet.com;maddr=3Dproxy.homenet.com</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">which is Billy's very first example on =
this thread.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">In this case I would want =
proxy.homenet.com to now route using the URI</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">friend@anothernet.com, which was my =
original point.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If the UA functions as in case (b) =
then proxy.visitednet.com (which assumes all</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">UA do case (b) )</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">receives</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">INVITE =
sip:friend@anothernet.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Route: =
&lt;sip:friend@anothernet.com;maddr=3Dproxy.homenet.com&gt;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">proxy.visitednet.com then pops the =
first Route entry into the R-URI and forwards</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">to proxy.homenet.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">which receives the following</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">INVITE =
sip:friend@anothernet.com;maddr=3Dproxy.homenet.com</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">which is exactly the same as if the =
UA/proxy were functioning as in case (a).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">So, to summarise, assuming UAs =
function as in case (a), if a proxy receives a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">R-URI</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">with an maddr that does not reference =
the domain the proxy serves then the proxy</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">sends the request to that maddr, =
regardless of the Route headers; if a proxy</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">receives</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a R-URI with an maddr that does =
reference the domain it serves then it strips</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the maddr</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and goes through the normal routing =
procedures. The only special case processing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">the result of checking the =
maddr.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">K. Robinson.</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Jacek_Grabiec@3com.com on 02/01/2001 =
15:07:13</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
</P>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;To:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
sip@lists.bell-labs.com&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; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;cc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
billy@billybiggs.com, hgs@cs.columbia.edu, Jonathan </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Rosenberg &lt;jdrosen@dynamicsoft.com&gt;,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
rfairlie@nuera.com, =
jhornsby@ubiquity.net,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
vkg@lucent.com(bcc: Keith =
Robinson/MAIN/MC1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;Subject: RE: [SIP] Proxy =
Routing =
Logic&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; </FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Jonathan Rosenberg wrote;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;To comment on the primary issue, =
ignoring the Route header if the request</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;URI domain is not your own, and =
sending it to that domain first, is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;dangerous, IMHO. Thats because, =
nearly as I can tell, it completely breaks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;the existing usage of =
record-routing. In the existing usage, a proxy copies</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;the request URI in the request =
into the record-route, and adds its own</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;maddr. Requests in the reverse =
direction will only get routed correctly</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;through that same set of proxies =
IFF each proxy uses the top route header no</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;matter what. If proxies start to =
only sometimes use them, we will end up</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;with incorrectly routed =
requests.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I'm not sure if 'ignoring the Route =
header if the request</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">URI domain is not your own, and =
sending it to that domain first' breaks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">anything.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">I can see it may add another proxy to =
the path, but at least all record-routed</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Proxies are on the path as well. =
Doing otherwise will break routing (I gave an</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">example</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">in one of my previuos postings). I =
would argue that proxy cannot blindly follow</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">logic 'replace RURI with Route' no =
matter what just like it does not proxy</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">responses</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">downstream if top-via doesn't match =
the server - it checks if it matches first.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;So, I would modify my proposal to =
satisfy some of the other requirements:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt;1. If there is a Route header in a =
request, that ALWAYS takes priority for</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;routing the request.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;2. If there is none, and the =
request URI has a domain NOT matching that of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;the server, but the =
address/domain in the maddr does, the server forwards to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;the domain in the userhost =
portion of the R-URI. If the neither the maddr or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;userhost have an ipaddress/domain =
matching the proxy, the proxy sends the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;request to the address in the =
maddr. Stripping of maddr is optional.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">your 2 suggestion is really close what =
I would have in mind. There's also</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">another</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">scenario: where Proxy receives a =
request with maddr where neither maddr nor host</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">portion of RURI matches the =
server.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Let's say proxy at sip.company.com =
receives a requests like:</FONT>
</P>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">sip:abc@someone-else.com;maddr=3Dproxy.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">.......</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Route: =
&lt;sip:123@yet-someone-else.com;maddr=3Dyet-yet-someone-else.com&gt;</F=
ONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">As Billy pointed out you, being the =
proxy, don't really want to pop Route header</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;blindly. I would rather</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">propose something along theses lines =
- it is really close to your 2 case (it</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">also takes care of scenario =
where</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Proxy has it's own outbound Proxy =
which may have its own outbound Proxy etc - if</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;you were to pop Route at</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">every hop the message would never get =
to the proper Proxies):</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Investigate RURI first:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">1)&nbsp;&nbsp; if maddr exist and it =
doesn't match your domain send message to:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; - address =
indicated in maddr and strip maddr.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; - or, if =
outbound Proxy is used, to outbound Proxy and preserve maddr</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; - or, return =
488 if unwilling/unable to forward the request (I explained my</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;reasoning for 488 in previous =
posting)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">2)&nbsp;&nbsp; if maddr exist and it =
matches your domain strip maddr and go to 3</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">3)&nbsp;&nbsp; if host part of RURI =
doesn't match your domain send message to:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; - address =
indicated in host part of RURI and preserve existing RURI and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Route(s),</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; - or, if =
outbound Proxy is used, to outbound Proxy and preserve existing</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">RURI and Route(s),</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">4)&nbsp;&nbsp; if host part of RURI =
does match your domain pop first Route header and go</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">back to 1</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; (now your =
RURI is whatever Route header contained).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">5)&nbsp;&nbsp; if there's no Route =
header do whatever you want (get contact from your</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; =
location/registrar server most likely) and go back to 1 (now RURI =
is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">whatever you got</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp; from =
location/registrar server)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">regards, Jacek Grabiec</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">sip:jacek_grabiec@sip.3com.com</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">_______________________________________________</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">SIP mailing list</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">SIP@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/sip" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></F=
ONT>
</P>

<P>
</P>
</UL></UL>
</BODY>
</HTML>
------_=_NextPart_001_01C07FA8.3679A930--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 06:32:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08102
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 06:32:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E620C44346; Tue, 16 Jan 2001 05:33:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lists.bell-labs.com (Postfix) with ESMTP id 3FD1444343
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 05:32:12 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f0GBVnC06270;
	Tue, 16 Jan 2001 12:31:50 +0100 (MET)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.38])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id NAA20907;
	Tue, 16 Jan 2001 13:31:33 +0200 (EET)
Message-ID: <3A643106.EE53DB55@lmf.ericsson.se>
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Subject: Re: [SIP] Mix or replace
References: <B65B4F8437968F488A01A940B21982BF9AB0D1@DYN-EXCH-001.dynamicsoft.com>
Content-Type: multipart/mixed;
 boundary="------------5F4BBE0E4D0C7575CC611F33"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 13:31:18 +0200

This is a multi-part message in MIME format.
--------------5F4BBE0E4D0C7575CC611F33
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

>>Hi,
>>
>>This issue was mentioned in, and is part of, the early media
>>replacement
>>thread, but I would like to ask about here.
>>
>>My question is: If we receive multiple 183 responses, with SDP message
>>bodies, from different locations, should we:
>>
>>1. Mix the media streams
>>
>>...or...
>>
>>2. Replace the media stream every time we get a new 183 response.
>>
>>My assumption was option 2, but since Jonathan mentioned the audio
>>mixing in a previous mail I would like to raise the question.
>>
>>The problem is that there be cases where one option is to be
>>used, while in other cases the option is to be used...
>I don't think this needs to be specified. If I'm in multiple calls, the spec
>does not say whether I need to play just one of the media streams at a time,
>or mix them and play both. Its a local decision based on the end device.

Well, this may work if your end device is a SIP phone, and you for
example can press some button to switch between different media streams
- or choose to listen to them all. However, that may not be possible if
you have a PSTN GW. In that case the end device is a PSTN phone, and the
user will probably have no control over the GW.

Also, I am not sure my 90 year old grandmother, or my 5 year old
brother, want to start do manual media stream switching when she/he
makes a phone call...
 
>In the case of early media, I can imagine a smart phone that creates new
>call apperances as it gets multiple 183s (each will have different tags),
>allowing me to select which appearance I listen to 

That is never going to work. Let's assume I am listening to the first
media stream, and then I get some kind of indication that 2 other media
streams are coming. I will have to listen to both of them to figure out
what they are about in the first place, and the more streams there are
the more of each message I will never be able to hear in the first
place...

>(note that there is a problem in figuring out which media stream is associated with each call
>appearance,

Will we even be able to pick out media streams if they all go via a RTP
proxy/firewall/NAT?

>unless we have some kind of rtcp SDES item that conveys the SIP
>URL, or define an sdp attribute for ssrc or cname). 

Well, that is not a bad idea at all.

>Another phone might always play just one and ignore all the others.

True, but then we have the race condition when I may hear different
things every time I call the same number, since it will depend on which
183 message reaches me first.

>Yet another might mix them, although I suspect that is not what you will want in most cases.

I don't even think that it should be a requirement for a UA to be able
to mix media streams, since that would almost require one to implement a
simple conference bridge in the UA...

Here is an idea about having some kind of media stream indicator, BEFORE
the media itself is sent.

When an UAS receives an INVITE, and wants to send early media, he could
send some kind of REQUEST (Note: NOT provisional response!) to indicate
that. Then, if the UAC wants it, he sends back 200 OK. After that, the
UAS sends 183 and media. If the UAC sends non-200 (maybe followed by a
BYE for that specific leg if wanted), the UAS will not send media (the
UAS can also choose to terminate the call itself, even if the UAC didn't
send a BYE). No, this will not solve all problems, but it would give
more control over the media, and when it's sent.

There are probably also better ways to do this than my example, but my
basic point, and the magic word, is MEDIA CONTROL :)


Regards,

Christer Holmberg
Ericsson Finland
--------------5F4BBE0E4D0C7575CC611F33
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------5F4BBE0E4D0C7575CC611F33--


_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 08:11:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10124
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 08:11:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C97FD44353; Tue, 16 Jan 2001 07:12:03 -0500 (EST)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id B0C1544336
	for <sip@share.research.bell-labs.com>; Tue, 16 Jan 2001 07:11:32 -0500 (EST)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jan 16 08:08:59 EST 2001
Received: by lists.bell-labs.com (Postfix)
	id 6819C44380; Tue, 16 Jan 2001 07:57:08 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from uk0006exch001h.wins.lucent.com (uk0006exch001h.uk.lucent.com [135.86.160.150])
	by lists.bell-labs.com (Postfix) with ESMTP id E0D6A4437D
	for <SIP@lists.bell-labs.com>; Tue, 16 Jan 2001 07:57:07 -0500 (EST)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21)
	id <CZ4F6TVT>; Tue, 16 Jan 2001 12:57:07 -0000
Message-ID: <475FF955A05DD411980D00508B6D5FB00122C583@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'SIP discussion list'" <SIP@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Subject: [SIP] Back-to-back UAs
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 12:57:05 -0000

I keep seeing mention of back-to-back UAs and I think I understand what is
trying to be done with them. 

I do however see an issue that there is apparently no documentation of this
concept in any draft. Therefore it leads to the question of when does a
proxy become a back-to-back UA, and therefore perform all error handling and
syntactic checking as a UA rather than a proxy. Because there is no mention
in any draft, it would probably never be identified in any conformance
statement, and an attaching UA to this concept might therefore see behaviour
that was not expected.

I also see problems where, because it is not documented, the impact of
interactions with other drafts may not have been assessed. For example, is
there an impact on the privacy draft, such that the identifiers passed using
the concepts of the privacy draft will never pass the back-to-back UA? Do we
have problems with any headers that have been ciphered, because we do not
wish to release them outside proxies?

I would therefore ask, if such a concept is meant to legally exist, should
be not at least define it somewhere. (Thats assuming I haven't missed it
somewhere!)

Keith Drage
Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: drage@lucent.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 09:43:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13281
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 09:43:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1989044364; Tue, 16 Jan 2001 08:44:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 6E98044366
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 08:43:00 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA16154;
	Tue, 16 Jan 2001 09:42:43 -0500 (EST)
Message-ID: <3A645DE3.FB6A69D1@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'mgovind@hss.hns.com'" <mgovind@hss.hns.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] Tel-Url query
References: <B65B4F8437968F488A01A940B21982BF9AB0D6@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 09:42:43 -0500
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: mgovind@hss.hns.com [mailto:mgovind@hss.hns.com]
> > Sent: Thursday, January 11, 2001 7:29 AM
> > To: sip@lists.bell-labs.com
> > Subject: [SIP] Tel-Url query
> >
> >
> >
> >
> > Hello,
> >
> > I have a query regarding the usage of "Tel" URLs specified in
> > the RFC 2806 as a part of the Addr-spec within the SIP Headers.
> > The ABNF for the Tel URL includes
> >
> > token-char = (%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
> >                 / %x41-5A / %x5E-7A / %x7C / %x7E)
> >                *(%x21-3A / %x3C-7E)
> >
> > which is a part of "private-prefix". These characters include
> > "<", ">" among others.
> 
> Thats probably a mistake.

As has been observed in the past, the RFC 2806 ABNF is a royal mess that
differs from all other ABNFs for URLs (not just syntactically, but
conceptually). It is hoped that the author will fix this in the next
version.


> 
> >
> > Do these particular characters need to be escaped if the URL
> > appears as a part of the Addr-spec within a SIP header, like 'From'?
> 
> THey need to be escaped, period. The "<" and ">" are not valid URI
> characters according to rfc2396. This specification defines syntax for all
> URIs, including SIP and tel.
> 


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 09:48:25 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13342
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 09:48:24 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2E8A844374; Tue, 16 Jan 2001 08:46:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1])
	by lists.bell-labs.com (Postfix) with ESMTP id AA90544358
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 08:45:02 -0500 (EST)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256)
 id <0G7900H01FJKS7@firewall.mcit.com> for sip@lists.bell-labs.com; Tue,
 16 Jan 2001 14:42:56 +0000 (GMT)
Received: from pmismtp03.wcomnet.com ([166.38.62.38])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0G7900EJ3FJKTZ@firewall.mcit.com> for sip@lists.bell-labs.com;
 Tue, 16 Jan 2001 14:42:56 +0000 (GMT)
Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258)
 id <0G7900A01FJKGD@pmismtp03.wcomnet.com> for sip@lists.bell-labs.com; Tue,
 16 Jan 2001 14:42:56 +0000 (GMT)
Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com
 (PMDF V5.2-33 #42258) with SMTP id <0G7900A01FJ6CP@pmismtp03.wcomnet.com> for
 sip@lists.bell-labs.com; Tue, 16 Jan 2001 14:42:56 +0000 (GMT)
Received: from omzexch006.mcit.com ([166.37.194.37])
 by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258)
 with ESMTP id <0G79004OPFJ0Q3@pmismtp03.wcomnet.com> for
 sip@lists.bell-labs.com; Tue, 16 Jan 2001 14:42:36 +0000 (GMT)
Received: by omzexch006 with Internet Mail Service (5.5.2651.58)
 id <CSHL69P8>; Tue, 16 Jan 2001 14:42:36 +0000
Content-return: allowed
From: "Ngo, Dai" <c-Dai.Ngo@WCOM.Com>
To: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
Message-id: <492EB4A3F68CD411ABE800508B69362E11C48C@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_y5qp4ptsquHSM0iIE2qdbw)"
Subject: [SIP] Feature="voice-mail" v.s Feature="voicemai"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 14:42:33 +0000

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.

--Boundary_(ID_y5qp4ptsquHSM0iIE2qdbw)
Content-type: text/plain; charset=iso-8859-1

Hi all,

I ran across another question and would like to hear other's opinion.

On page 4 of the draft-ietf-sip-callerprefs-03.txt, it says,
feature-value="voice-mail" (with a hyphen between voice and mail). On page 1
and 2 of draft-mahy-sip-message-waiting-00.txt it says feature="voicemail"
(without a hyphen). Which way should I use? 

Thanks,

Dai Ngo

--Boundary_(ID_y5qp4ptsquHSM0iIE2qdbw)
Content-type: text/html; charset=iso-8859-1
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>Feature=3D&quot;voice-mail&quot; v.s =
Feature=3D&quot;voicemai&quot;</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi all,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I ran across another question and =
would like to hear other's opinion.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">On page 4 of the =
draft-ietf-sip-callerprefs-03.txt, it says, =
feature-value=3D&quot;voice-mail&quot; (with a hyphen between voice and =
mail). On page 1 and 2 of draft-mahy-sip-message-waiting-00.txt it says =
feature=3D&quot;voicemail&quot; (without a hyphen). Which way should I =
use? </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Dai Ngo</FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_y5qp4ptsquHSM0iIE2qdbw)--

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 10:05:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13761
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 10:05:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BC2624434F; Tue, 16 Jan 2001 09:06:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id 4D2FF44336
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 09:05:54 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 16 Jan 2001 15:05:42 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id PAA05473; Tue, 16 Jan 2001 15:04:24 GMT
Message-ID: <3A6462F9.9977649@ubiquity.net>
From: Neil Deason <ndeason@ubiquity.net>
Organization: Ubiquity Software Corporation Limited
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Rohan Mahy <rohan@cisco.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Need rough count for interim meeting
References: <5.0.0.25.2.20010115114451.0245cc60@imop.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 15:04:25 +0000
Content-Transfer-Encoding: 7bit

Is there a decision on whether to discuss more open issues than 
REFER? If so is there an agenda available? Can we also make
the time convenient for people outside the US.

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

Rohan Mahy wrote:
> 
> Hi,
> 
> I need a rough count of those attending in person and by phone, so I can
> reserve the rooms / conference bridge, etc..
> 
> Please reply privately to me (or click on the links below) and I will post
> a count back to the list.
>         mailto:rohan@cisco.com?subject=AttendingInterimSIPmeeting
> 
>         mailto:rohan@cisco.com?subject=CallingInterimSIPmeeting

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 10:25:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14191
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 10:25:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B565044357; Tue, 16 Jan 2001 09:26:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id A926B4434F
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 09:25:30 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA18848;
	Tue, 16 Jan 2001 10:25:16 -0500 (EST)
Message-ID: <3A6467DC.B8AAF213@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Grant McSheffrey'" <grant.mcsheffrey@empowertel.com>,
        Sip List <sip@lists.bell-labs.com>
Subject: Re: [SIP] Timestamp header
References: <B65B4F8437968F488A01A940B21982BF9AB0D9@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 10:25:16 -0500
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> The spec is not clear on this, saying simply that it should be echoed. I
> would imagine placing it in all responses, provisional and final, makes the
> most sense.

Note that because of the different origins, the delay for the 100 may
differ from the other 1xx and the final response.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 10:48:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14578
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 10:48:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 840CF4435C; Tue, 16 Jan 2001 09:49:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103])
	by lists.bell-labs.com (Postfix) with ESMTP id 3EC5C44358
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 09:48:54 -0500 (EST)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-green.research.att.com (Postfix) with ESMTP id 300BA1E034
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 10:47:03 -0500 (EST)
Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id KAA28012
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 10:47:02 -0500 (EST)
From: William Marshall <wtm@research.att.com>
Received: (from wtm@localhost)
	by fish-ha.research.att.com (SGI-8.9.3/8.8.5) id KAA37572
	for sip@lists.bell-labs.com; Tue, 16 Jan 2001 10:47:31 -0500 (EST)
Message-Id: <200101161547.KAA37572@fish-ha.research.att.com>
Subject: Re: [SIP] Back-to-back UAs
To: sip@lists.bell-labs.com
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 10:47:31 -0500 (EST)

I think there is a simple solution to the documentation of back-to-back-UAs.

SIP RFC2543 defines the protocol between a client and server, UAC and UAS.

The UAS may not be able to satisfy the request by itself.  It may need to
consult with other devices or other servers.  If it uses a protocol such
as H.248/MEGACO/MGCP/TGCP/etc to do that, it is just a UAS.  But if it uses
SIP as the protocol for communicating with the other device or server, it
then includes a UAC - making it a back-to-back-UA.

The proxy server, redirect server, and others are then just profiles of
the B2BUA.  So if the B2BUA meets the restrictions imposed by the profile
definition, then it gets the title of proxy (or redirect server, or ...).

So, in the same way that a forking proxy can send out multiple INVITEs
in response to a single INVITE from the originator, the UAC initiating
the whole session could also send out multiple INVITEs, and deal with
the multiple responses, and send a CANCEL when it gets a 200-OK from
one branch, etc.  This makes a forking proxy nothing special beyond
a normal UAC.

All the rules for forwarding responses can follow from this model.
The stateful proxy generating a 100 response, and absorbing a received
100 response; the stateless proxy forwarding a 100 response; the final
destination sending a 180/183/200 instead; all are just profiles of
allowable UAC-UAS interactions on all the separate interfaces.

Since there was discussion in San Diego about restructuring the RFC,
I believe this would be a direction to simplify all the complexities
in 2543 today.

Bill Marshall
wtm@research.att.com

-----original message-----
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'SIP discussion list'" <SIP@lists.bell-labs.com>
Subject: [SIP] Back-to-back UAs
Date: Tue, 16 Jan 2001 12:57:05 -0000

I keep seeing mention of back-to-back UAs and I think I understand what is
trying to be done with them. 

I do however see an issue that there is apparently no documentation of this
concept in any draft. Therefore it leads to the question of when does a
proxy become a back-to-back UA, and therefore perform all error handling and
syntactic checking as a UA rather than a proxy. Because there is no mention
in any draft, it would probably never be identified in any conformance
statement, and an attaching UA to this concept might therefore see behaviour
that was not expected.

I also see problems where, because it is not documented, the impact of
interactions with other drafts may not have been assessed. For example, is
there an impact on the privacy draft, such that the identifiers passed using
the concepts of the privacy draft will never pass the back-to-back UA? Do we
have problems with any headers that have been ciphered, because we do not
wish to release them outside proxies?

I would therefore ask, if such a concept is meant to legally exist, should
be not at least define it somewhere. (Thats assuming I haven't missed it
somewhere!)

Keith Drage

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip


From sip-admin@lists.bell-labs.com  Tue Jan 16 11:17:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15192
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 11:17:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 168D844357; Tue, 16 Jan 2001 10:18:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pallas.host4u.net (pallas.host4u.net [216.71.64.48])
	by lists.bell-labs.com (Postfix) with ESMTP id 6DD6C4435C
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 09:59:29 -0500 (EST)
Received: from ranwin ([212.199.50.10])
	by pallas.host4u.net (8.8.5/8.8.5) with SMTP id JAA17278
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 09:58:08 -0600
From: "Ran Milshtein" <ran@kagoor.com>
To: <sip@lists.bell-labs.com>
Message-ID: <DBEGLANIPBBIDHAFHFNOEEKECAAA.ran@kagoor.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_00A9_01C07FE5.E0C1F5E0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-MS-TNEF-Correlator: <DBEGLANIPBBIDHAFHFNOEEKECAAA.ran@kagoor.com>
Subject: [SIP] SIP calls generator
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 17:58:06 +0200

This is a multi-part message in MIME format.

------=_NextPart_000_00A9_01C07FE5.E0C1F5E0
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: 7bit

Does any know of a good and free SIP calls generator ?
Thanks in advance,


Ran Milstein
Kagoor networks Inc.
Tel   : 972-3-9565333 ext. 211, Fax : 972-3-9565622
Mail : ran@kagoor.com <mailto:ran@kagoor.com> 
Web: http://www.kagoor.com/ <http://www.kagoor.com/> 


------=_NextPart_000_00A9_01C07FE5.E0C1F5E0
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Disposition: attachment;
	filename="winmail.dat"
Content-Transfer-Encoding: base64

eJ8+IgYPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5wQAAAAAAADrAAEIgAcAGAAAAElQTS5NaWNy
b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANEHAQAQABEAOgAAAAIANgEB
A5AGADAdAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB
AAAAFAAAAFNJUCBjYWxscyBnZW5lcmF0b3IAAgFxAAEAAAAWAAAAAcB/1RrDB6cK7MxKSY2Yo1eU
aoET6gAAAgEdDAEAAAAUAAAAU01UUDpSQU5AS0FHT09SLkNPTQALAAEOAAAAAEAABg4A9I8Z1X/A
AQIBCg4BAAAAGAAAAAAAAADloJpobFsxRrDYFLitbRmFwoAAAAsAHw4BAAAAAgEJEAEAAADEGAAA
wBgAAEg1AABMWkZ1d99ifwcABgEBC2BuZzEwMyY3AGQAcmNwDdAyNfo1DGBjDUQAQAMwD5MA8vMN
pw11ZmUN4gH3AqQDY4kCAGNoCsBzZXQC0VBwcnEyAAAqCqFusm8TkCAwAdAB0DYN8HAwNTA0FWEB
0BVQNH59B20CgwBQA9QTPxRLYn8VIRWQFPIaNBYQBxMCgzmiNBLOMjM4GJQgB234IENFG0QPIBvO
FYAc7zkd9XlyG0QOEBLdMTbXF3EgPwOCRwnRaxtEHNFtIk4yI18d9FQIcBtEOWECAGJpZGkDNiKY
N4ciESbfA4IoSGViCXD0dykXJDAC0SjvKfQc338rZgcQAaAOsCxGF3EiTTjWNi5/HfRCB0B0DrAs
Vf8moResHLgHEx5GDeE0bx/3/zYFIZUN4B7RF6wjKDYEJMj/DeAyATneJqY2BCgmDeAiEf8s9Tnd
Kkc2BCvdLmE/Xy4M/0FFL/wosTndMfc2BDOGApHVCOY7CW8wSU9lDwFKev8PAktfTGhKZA8CSu9O
v059z03/TC9KfxGgMjhUSlVh/1UfVilKZFZSVL9Yj1hNV8/7Vf9ZxDkmoF0UXnFWk15w7VRDNQBQ
XRQ1NvBWkxTgoQKCc3R5bAeQaAngOnQAAmwKs2IhGBBccXkK0WxpAUAFEAFAA/Bk9mNiMwBgcwqw
YkAYIGRSCG51bQIAYWF1dDJvDVFqdWFgBRBnaF50Y3EKAWNACgFpAZBwujADMGEAQgvhG6BjAEHb
EVhjMG9i0QBBaA6wYuDZZ6JkYmnTAUBjCcAtAPloc25wDeE28BFUa3RjIf9mIGlUZ/trmWuUaU9q
X2tv4Wxzc25leBhwB7AFsDcAwAJzYixzAFBjCnNiy2gQdXFhFTBcawngZRC/Y79kz2XfZusMMGel
NC5gz2iJdkAEoAuAZzMmoG8v/3A/cU9sb3slbi58D30ffi/9cb9id0AJgAIgZ3FytWHA8w1ggpEg
MXOPYVAmoHTff3Xvdv94D3kfeigOYWe0M/8yAGiPg1+Eb4V/bMmQBW4v/5D/kg+TH4Y/h0xhE3PN
NvD/iY+Kn4uvjL+Nz3ouVmGQP/+W/5gPmR9syoD/lk+lH6Yv95l/mo+H8TOb32FQG6CdL/+eP59P
oF+hb6J/G6Cjr6pv/6t/rI9szKjPqd+4r7m/rQ/5rh8gNK9PYVAPILCfsaT/sm+zf7SPjo9npmbB
ty+97/++/7pfbNnKNLx/yx/ML80/78C/h0xNIMLPczIAxA/FH//GL8c/yE96iCMgyk/RD9If/9Mv
bLrdNc+/3i/fP+BP0/9th0w2AoIUUGN0oGdyZOstEDOwdhTARAEQ2nAzoDQgUArAYQnAZ1BoIB5G
AiHV/3SRw+RmaS0/PwHd8WNT7YPYuCwAZHJn7wQX4O8idzRTsRhAcP8B0GeB2W/af9uG7YNnP2hP
/+Pv5P/mD7sfbZ/jT/Z/94+f5n/ni2Bw6sDbgXQt62AVA2E6MnBvAUBTdWIKagWQdAFARGF0Zf46
6790kdck7V/ub+9/8I//8Z/yr/O4YbCHww7xoqwmoP/0//v//Q/+H/k43KD51AyoP/rfDc8O3w/v
/x8ALFJl++ogOnEgK+DpwIJgAo90kb8/IAPvBP8GDwcfCC5vCODtZuFlYZDqIGwswAkvCj+XC0Qs
sBVBYmJQdDiiuyfKPxQPFRlubzIwb2/+ZhW/EL/O/LbptuImLyc/HyhPFo8XmyRgGPBwbHmuL+tw
HjBiYGQZZXMZ3/90kVowGz8cTx1fHm8ILyFv//N/JP8sXxTPLv/5D88/E1//PY8+ny+vML8xygFi
AQQCP/10Rjli/9j/ON/bH9wlJBP+OfQ/PE9DD0QfP3/5j0Ffv0JvUh9TL0WfF9dPcERXMPdMsF1A
6rBN3EDpBjfj6db/YpVYg1gAVKZeo+dW6YJL8C8ZIeewTBBykWMBIHBvBRlBRXNQaWxTdHn/IOBB
IFynXsFdb1iR6pBQMs43VKZkZ1+pSHlgcU5h+mtcpzJjD2QY9CFk+efS61+463BsVyB355Bmm4h+
/50MS09MX01v2+pPv1DPV8//WN9T/1UPVh9z33Tvdf9aX/eHM21wYZAtYbIBkHDgYMBwdHVyZWxA
6RN/YHZkdGJg4HtVZwAuYHeabn+BXOwgYHF3MUpQazrggRRo4lA4sYFhsHK0Z2wbADk7AIKicoLz
7+xx54BukOxiZ3AwSPA0YZ9uYWtwbpBm0OHwdG4BwN9u8CmQ6dB50C5ReHiAhLDUb3kpkFya8HAj
UOxwv7JALmDqkWbQbxCGcGQAwL2AMG6xUHrQLlFvEWPqYNcyEGRhibFtI1JlejAyEHJ6hlJkZ4Ki
2+CLIWjviWM0INwAizB2i/mKsXDguTqxNzB6sYyQjXU5gmD/i7OKsIFwjHOPQwHQh2ArMB97oIZR
YgBgcBIgdmll9Hdr2+Bk7PCRMmEQbzDzLAHcAHBnNmKbQpKVibDub3EQbxAx0HSAwCCxhaL/lCdx
AGGwcDBvEC5RiNBxAP9wcYAhZFDngCog52CI0G7w/4jQgCGRgW3QlDCSIW6QgDB+d5fzgCHscHtw
bdCF0HL+a4nRXdF5UK6A6SJI8GFAQ4bB6jBDOlxcAJBvLesRbetgYdBlNwBcTY96UC6QYKCFsCBP
ZjSQv4mQm3CdJnODh0Bhsi7noOZ06RPnYGNre3AgcIYw+4BQCxFw6SKgMdvgcLCgIv8g4IWwsTGg
QHBA3FCgInDTLaGTYpPQcEBtoZNmaPs2gKK0eItVpBN/ATIQipDVotJ5pGl5pSh3o+SnQLZro2SY
kXQAQaAieqGTdW3gZCthNaARoFGuQCAbI1FgcFRmoWxRc3YgJjF/kqnlZkZt4HBIdarkMKteVqxv
q/Bh0Gz1qqgzrl1CrCGq5GxgoMC3hDGxoZITeJJjsgV5soV/nKExwLN3o+GzlaGBs5Vin7KjN2Bt
cHxBsaFoOUEgczQwthJnb28w2CGylGj9t4I1EhCSgQtwl7GV4LkiY9wwC4A0ODWCULngNzY0nyOs
IXV7kNXQODi9etAztlC2YedghhBlujDJtvBjNHlQMjbYMLigFDNhgQBi2+AyODYBXsCJUE5HDQoa
BAoAvmANSUhEUgm+YAZAvmABXAgDIb5hp2GC+75hAXMAUkdCAK7OHOmBvmHAUExURf/BQAL+wWD8
//z7//sA+v/6+f/5+P8A+Pb/9vX/9fQA//Tz//Py//IA8P/w7//v7v8A7uz/7Ov/6+oA/+rp/+no
/+gA5//n5P/k4/8A4+L/4uH/4eAA/+Df/9/d/90A3P/c2//b2f8A2dj/2Nf/19YA/9bS/9LP/8/A
zf/NzP/MvmHIjw/Jn8qvy7/MNUvSa4cBvmEMY21QUEpDF2FAOuALkAK+YAkC3ARSKb/yYktHRAAQ
iAUdSM6R9klEAEFUeNrt3VtzAKLKAoBRFS+gIAbvd0XQxTD/xQKzdrBnkj0zSaQAOSXJsNZr0IcA
7iq/InQ3rRYBzD8A/N2eDAEAAgLQ0IAAICAACB4I1ULU39Xv1vvwtwQApB1PVof8cn0AfLxe8sNq
ErcAjRAAHwUkSjcARbFfpkmv024Ad3pJutwXxSYAjQwSAO8EZLgAKg7z+Nc/x/MAQ7EaGiYA3ggA
yGh7XsZ/viIAXp63IwMFwB8AAjJYZ7N3/lMQFc2y9cDwAfBLAECm03zRff+qAO4inxorAF4HAKS/
2e2Sj69LAHabvtEC4CUgAKf5jVfOT56EAdiQ7OFpfPO14wjswYDesF16LLMAEz05pqkxA+AAn/uP
46DUUSYQg+PRTdcgrVGWgJQ8CytJMg/AYAAar38alz9McQB8shgLoOk23wDWX5U+jXe+MQByAM02
3bVCAgDS2k2NHUCTDQDyJCwgSe5YE4CAJlsvWmEBNKCA1kYPoLlGWbpgACBdK7EAPrOnAC/EbAE0
xvD8AO/x7SE//tHZACumAJpqtWyFAd/QtVwZQYBmigCKuEpA4sKL0kABmik9tKrYwHUAcKgiQDNt
5tUQAmI7OuyQtX/+hAcrC8Bx0TaKvoAQFBetaugAvRQIAIAGmeyrBmQ/IjHt4fRzES5wQCwA5AVo
pFeLqAIgA/KyjAvuoPlxABBvlYAkuVEEAGigS69qQHoXDKMI1uDXcMBtrp0gqgHpXI3sgAM9Arbu
4KT9aBQBBCJEvxC4jX/n8BDEAEN0AILYBwJAABA70QEI4iwsgfRgOI0XgCDe9JIAbyQEIIx3ogMA
EORlEVVYQF4ALeMCoEmias8gMOIiMobmMPRqACFvAIt4ARprAHiucA8RnYdGABCgqbaz8M/OFLbG
6FCx6IH0o90IbGT86mBrvQj9EORibfTkkGzw6kBI3lKSfGD7AJoAbLoL+9xuauwF6mDtf3B6GTah
AwA0Xv80Lv+h8Qipb+TqYG6UlX0ADJIkVmAB0GoAPRzLPQ8fHI8AD0YNgFYrPZZAuQdJjqlD83D4
AHEPkt3+HGScALn9AODZ6HTrQFqs+cnjD9+w9AA3u90N/8dKdgAby68A+I/pNIRffDtQVneRT+4A
AAC/Gqyz2TvHQLtHs2zt+Ntw/gBktD0v33hJYRC8PG89AMEtw1UEcZjHgJB4fihWAl7aAMB7onRT
FAD7ZZr0Ou12pwCXpMt9UWxSrwA/B+BD7XiyOgDkl+vj4/WSHwBWk7htTAC+muCnv545BtNvCo8L
WoCAv9CTIQBAvxDyENngBAS/MNSwDVAMxgiAr67Y5Lk+fRkAJg2gdlG6KYqA/TJNer2OO9ngAm4r
kBWHefzmnwIFDhA/GW3Py/gEvQsOAd8N1tksSHr/Eg1Q4DffAf2E6BoR8Rf9zS7CUBIqEfG/RuDg
LZcJAdcg//GQjW+6TgG/EHgtPSa3XSgB1vC8vv84Dm68AlIM0yoaZcmtlwIK1yA/9U/jm68CFdng
ftrMb79WsxRh5lCVuPbQAnDXnRAoSlwt1vD8+pAoc6K12IHDKOv/kFwX4SBhOyt1udiB3fACHBPB
5a2W5a4XEdngvomKF9EoLz2ElPzYck2ZTejyIRSzdsbgYBPB38RFRNlP1xH/mOwQkQCIZRfxFkHf
HVINUCAgQKmDeBCRZ5dCntbAEODaEdngAgw8thCQDUHgXvwLifCQIB72YcQyXvRhJEgI9LBHmQzg
xGEB7eAE+RTHuWsSQMDX8yleKODAAEBf0Gd4pa3WwHwIQelBvxAIEJX9hB+W2IFd2YW88iEQd8Nz
JNbwBNjOIQ4BAKOsKyUxWC8VJYKDwEDyFkBAE/0g+ad6uhPZ4EJ+UKrLbEca4QEfkaqg/VT3T2Me
ceAnICCUJVW/Qr8QmhgQkNbDcdbhBPxUYKfHpOpX1xAm4AMQ0nrIxik36DSvBPoV13DQxIC0+iCb
XVLxKw0goInB6AC1pvmiWyymEYICEtngyv9Uj7bnAmXnQACU/6kerlCKwzwW2eBKLnBHAOmmKPbL
NOn1CjosAcggUA1MI8AAl7kDufftgkad1wCI1sAxstbkAiLW8PkylnyN1sQyCNeE13nXcv/XTDKS
10oz29cQNawxzDWfEzav1sBQ/sdA6bO4Idl026YMwM+wGZ0gXpIu90UHcNLIAqz08EhZcTw/FAir
oXn2cJCAiCwQz9uRmT8x8qJZELYemDu/MCmvuxDIpyYPDMACJLuoTd/0PoGAAVCTJ/FACTHOHkwg
15AEMkj/0BkEP0AmcKN7QUHyugfJPAf0EJAgEOOTtVjXYBJiReYAiURyNzWLRHEgEMmdagLW4CEW
a8LT8fEBulZi9PAxwkDI/cy25hFBAUQIZ68oQvEQy5WJIULycRGZSUIBcHCEKi/XkIRwnglCgZCJ
i7apQvJFbBMgoAQkwH5iSmKAJKAhRHEkPZhKQgGQ5CSmEkEB9C5MA3SuIUwDtB9NJThU3Isz8/E+
kBAP9OBKgIhlGUsyxEbAYEIQ4igTSU8yMEVPMjh3QgHhJoW+0E7hK21KccghADWTAHd27VT9AIZP
sAk8LiIzA0jgHxBe1W/4BJsAwC3iBbi/PKkA+g31bwKPzkMCE0jgb9WfHtS/IAl8tjWPUYC3WgJW
UdDa/3/UzUYBR0Dg7ib7qt9QQPsm8MXaNM7AXwJcUcG6N4En+cBBVpK76u9/7VLwdwBTswhQh828
2kDn694EbhPtEE0Aqi6iqnkT+Pgk1DfNcLWIKFAPq6DmTeCJFURgtfkwIJC33kW844CDCQgEqMsa
QIXfRNQCu1IQOTpEEaBGAcbQLPiztW4CHwBn7j8A6jTKsgBu4Edr3QQ+PwB5/gFQr/V6EQj4yRpX
IbuN9VcAADUbDALP5K1IbxN4AxFNHDpiwAAXNd0FfayuUwJEQBF2ABbApxACdPcwTaeIxMvzQNbj
c4BPouTB/gRMHWIR8fxQrLwSgB9g8xi8IB+D3AD3FJFOL0mX+yiiKDZ7kLbpAJOHAGO5pwo3niLy
APR/cr3kh9UkAG63zRTAZ5MeIMvcgzhFDhCf90Ig4ADPQZwi8jCLSNHp1kRQThESALVA/mZ3y7+x
Z8KvgS0w4qODFW0CB8AADwbrbPbOOtkIyCZw3KAw2p6XsG+85TbdUGnCTQV1LB978kBp0R0PNp12
AvtZgLg94ADcoB3Y5nxY0QjwC/bG+x+AUz4SpJZ6nP2wAb5hSUVORK5CYOaCf5CwD3BOm+Cq1ZtR
WCc1Y5uccsFDo0Bt932wc2iciFOKYH9ge6Bywf5UkwByEHOzkiCHcJnxdpbrmsCogC6NoGZwz6ww
rBB9ucBzqu+r8a8RfZB53yDJl8FlV4UgdGit76vwBkyUcX0fIGJXTW/rioB7ZDl6SkKfd3tvfiGE
YXmH8HRJbkOW8L5sgddwsZmAiCCQUHKaIPeW4JDAn/Bch6CIQIUhhXKeZ5WwmsCZcHcAejmZgPWU
cXiSgGWBsJYwhnClcc+FIXyCn6B80DM2orGFIuehYJWghJBjbKABoIC48LGFEWx2bI4AuPB1taDy
bbjhcWOKApZQmUCKkv+RgYdg0xC4w6pguQCxgZeQ8aiAYSAuekKJ+JEQirL/hJGLH4wvjT+KNLaR
kFGPcv+Pb5B/kY+KYRAQkuCYYI8P65QflSkpjcw1kt+YD5T6uGIgKKthmY+KQzaW3++b75z/ng+K
Fjefo4r/oR//oi+jP4pwtyGfz6Wfpq+nv/+KNIbQpI+qb6t/rIm1YK8QO3Xws/BhvXCFYISUXHHf
ibCG4bVQiIC1UHd80IgR7bLyYX8wt6BwdbC0gorAJ65giVCJYHRvtIBkauZ1rvCIgGdoheG9cLgA
O3yBuNBplaDOMIVjY2hNtIBmr0C4MHMyEBBjj7hBeZCZQLygMTAzpGA0bG+4BWh1ELgUZGKbuAOY
4GOIcrkDbnC5cf+SwLkUvBSyo7gBuEG4i7w5/7w0ud+677v/vQN/ULfThWD+Y7iQmOC4MrjRvUXD
xcRyFERvc6AglRB5IGswbm93IHVgxgAgZ75vf9DGAYVQglHDe2LEL9fD48iAyOJmddBlx3/Iv+HF
VVNJUCB24HsgxfA2Z4dghnBhtdCE4D8N2gqx8iB2QJUQa8XwsoH1tgB2lRBjLsDOdcqvy7//xWTQ
BrHzhWOy84Ths3+0j/+1n7avicHEztCb0XXS+7JN/7iQvvCzP9Vv1n/Xj7d/uI//uZ/Ar8G/vM+9
377v5A/lH9/mL8MjeQCDkHXwZvpAdeD/4XCJ0u3hr4Cu8MNI0W/RsQAgQVVUT1RFWGBUTElTVIVg
f2AgsCJFLW2ycN1QU+CAem7OEHV10DKgekLt4XLWc4SQ7w9cxmBwdTDGob/wKeiF4rHjJuKx9QZS
lRC+IHUAhaCGYK+AznVLeaDnxwDOQIhQdHfOMM8hg2CcYy7OdoOQOTAgOoBQAa/gLTMtOTU2NYfm
YOdAd+IgMjExLtCIRmF4+zs2MjLOdf5N8kL7QPNC7ZLuX/RP9V+L9m8BNyA+oFBFUvFwXE5L8fDy
Mt/gOnMwbuRAa/lDLmN0EPMRAD/vAU8CX/csidJkzhDiQO2SJYVgYq+AODk5QNDJAOp5+brOEYyC
QShAAEupCwJwAQMVcAHgDA0scAFtAGEAAGkAbAB0AG+QADoAcg7BbgAj0DprDsFnD0EPUA+QLgD+
Yw9BDrBwAHCz83/REeJi/69AdyDi0uOwB58S4hNmCN//91kFfHCzBq8HvxWv90rOdfhXZWL+3//v
GU8aXxtvAwQs4KB0cDovL3f1I9AuBbgvBl8ffyCPIZ/5Cp9uOdLQC+8M/yr1ENC9cABoDyEPMGqg
D3AvLbH/UEAuAhDQEB8OoS3AEV8Sb/8TfxSPFZ/3OyNvJHMYXyXf/ybvNP/bT7KC0+/d797/4A//
4R/iL+M/6k/rX+Zv53/oj//pn0TPRd9G6LHdPP8+Dz8f/0AvQT9CT0NfSm9Lf0aPR59/SK9Jv1ZP
V1/Cv++P2vt9AgBhcAsAAYAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwAVgAggBgAAAAAA
wAAAAAAAAEYAAAAAEIUAAAAAAAADAD6ACCAGAAAAAADAAAAAAAAARgAAAABShQAAjmoBAAsAS4AI
IAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwBNgAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAA
AAADAE6ACCAGAAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAMAYoAIIAYAAAAAAMAAAAAAAABGAAAA
AAGFAAAAAAAAHgBxgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsAcoAIIAYA
AAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAHgCFgAggBgAAAAAAwAAAAAAAAEYAAAAANoUAAAEAAAAB
AAAAAAAAAB4AhoAIIAYAAAAAAMAAAAAAAABGAAAAADeFAAABAAAAAQAAAAAAAAAeAIeACCAGAAAA
AADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAACwCNgAggBgAAAAAAwAAAAAAAAEYAAAAAgoUA
AAEAAAACAfgPAQAAABAAAADloJpobFsxRrDYFLitbRmFAgH6DwEAAAAQAAAA5aCaaGxbMUaw2BS4
rW0ZhQIB+w8BAAAAqgAAAAAAAAA4obsQBeUQGqG7CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABO
SVRB+b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3NccmFuIG1pbHN0ZWluXExv
Y2FsIFNldHRpbmdzXEFwcGxpY2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcUGVyc29uYWwg
Rm9sZGVycygxKS5wc3QAAAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAAuAAAAPERCRUdMQU5JUEJC
SURIQUZIRk5PRUVLRUNBQUEucmFuQGthZ29vci5jb20+AAAAAwAGEEuRP+kDAAcQ1AAAAAMAEBAA
AAAAAwAREAEAAAAeAAgQAQAAAGUAAABET0VTQU5ZS05PV09GQUdPT0RBTkRGUkVFU0lQQ0FMTFNH
RU5FUkFUT1I/VEhBTktTSU5BRFZBTkNFLFJBTk1JTFNURUlOS0FHT09STkVUV09SS1NJTkNURUw6
OTcyLTMtOTU2AAAAAHdI

------=_NextPart_000_00A9_01C07FE5.E0C1F5E0--


_______________________________________________
"This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip
to subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body"


From sip-admin@lists.bell-labs.com  Tue Jan 16 11:26:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15485
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 11:26:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8DC744437C; Tue, 16 Jan 2001 10:27:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by lists.bell-labs.com (Postfix) with ESMTP id AA83E44374
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 10:26:39 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA01656
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 11:26:25 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08829
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 11:26:25 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <CRQSS9XH>; Tue, 16 Jan 2001 11:26:24 -0500
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6ED17@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Changes to List Policy
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 11:26:19 -0500

As you all know, the sip list is very high volume.
To try to ease difficulties for many list members, we are going to
move "newbie" type questions, questions that ask how something
already an RFC (or about to be) works, from this list to the
sip-implementor's list.  This list will be the place that
we discuss new protocol development.

Both lists remain unmoderated.  Anyone is free to subscribe to either, 
or both, lists.  We can't stop inappropriate postings, but the 
chairs will try to cut off discussion on this list, and move it
to the sip-implementors list if it covers existing SIP.  I have
assurances from most of our more prolific assistance providers 
that they ARE subscribed to the sip-implementors list, and they 
WILL continue to provide assistance on that list, as they do here.  
I urge those of you who we have not spoken to, but also provide 
this essential service to continue to do so on the sip-implementors 
list.

To subscribe to sip-implementors, send mail to 
majordomo@cs.columbia.edu with "subscribe sip-implementors" 
in the body

Thanks

Brian

_______________________________________________
"This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip
to subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body"


From sip-admin@lists.bell-labs.com  Tue Jan 16 11:45:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16005
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 11:45:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 863D14433C; Tue, 16 Jan 2001 10:46:04 -0500 (EST)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id 4EA1E44336
	for <sip@share.research.bell-labs.com>; Tue, 16 Jan 2001 10:45:33 -0500 (EST)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jan 16 11:42:42 EST 2001
Received: by lists.bell-labs.com (Postfix)
	id 4530744380; Tue, 16 Jan 2001 11:30:51 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5])
	by lists.bell-labs.com (Postfix) with SMTP id F06064437D
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 11:30:50 -0500 (EST)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id KAA06430; Tue, 16 Jan 2001 10:30:48 -0600
Cc: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id KAA06422; Tue, 16 Jan 2001 10:30:45 -0600
Message-ID: <3A64772E.29AC3565@lucent.com>
From: Vijay Gurbani <vkg@lucent.com>
Organization: Lucent Technologies/Bell Laboratories
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Vijeth D <vijethd@rediffmail.com>
Original-CC: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
Subject: Re: [SIP] OPTIONS request
References: <20010116072629.9463.qmail@mailweb14.rediffmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 10:30:38 -0600
Content-Transfer-Encoding: 7bit

Vijeth D wrote:
> 
> Hi,
>   If I am a UAS and i recieve an OPTIONS request on what basis do i decide 
> whether or not to send a response?

Well, a UAS that believes it can contact the user MAY respond with a 
capability set of the user (codecs, etc.).  Even if a UAS does not want to 
return a 2xx to OPTIONS, it should return a non-2xx final response; a 501 
with an Allow header would be appropriate.

This is really discussed in the RFC.

> Should all OPTIONS requests be authenticated?

No.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

_______________________________________________
"This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip
to subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body"


From sip-admin@lists.bell-labs.com  Tue Jan 16 11:48:35 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16107
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 11:48:35 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 21F914438C; Tue, 16 Jan 2001 10:48:06 -0500 (EST)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id 7E7CD44379
	for <sip@share.research.bell-labs.com>; Tue, 16 Jan 2001 10:47:32 -0500 (EST)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jan 16 11:44:49 EST 2001
Received: by lists.bell-labs.com (Postfix)
	id C7C1F44384; Tue, 16 Jan 2001 11:32:58 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5])
	by lists.bell-labs.com (Postfix) with SMTP id 7C70B4437D
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 11:32:58 -0500 (EST)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id KAA07310; Tue, 16 Jan 2001 10:32:55 -0600
Cc: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id KAA07302; Tue, 16 Jan 2001 10:32:54 -0600
Message-ID: <3A6477AF.EE74C31A@lucent.com>
From: Vijay Gurbani <vkg@lucent.com>
Organization: Lucent Technologies/Bell Laboratories
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Vijeth D <vijethd@rediffmail.com>
Original-CC: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
Subject: Re: [SIP] REGISTER requests
References: <20010116072822.26429.qmail@mailweb12.rediffmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 10:32:47 -0600
Content-Transfer-Encoding: 7bit

Vijeth D wrote:
> 
> Hi,
>   What does the REGISTRAR do after recieving a REGISTER request i.e, a 
> valid request with user name password and the like? 

Save it in persistent store.

> How will the REGISTRAR find the IP address corresponding to the SIPURL 
> being registered

Contact header.  All this is included in the RFC as well.

> and how does he update the Location server of the same?

Implementation specific.  Depends on if the Registrar and LS are co-located,
in which case a functional interface suffices.  If they are not, some sort
of middleware (CORBA, RPC, LDAP) can be employed.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

_______________________________________________
"This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip
to subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body"


From sip-admin@lists.bell-labs.com  Tue Jan 16 11:59:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16384
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 11:59:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B203744383; Tue, 16 Jan 2001 11:00:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 41B4244336
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 10:59:20 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0GGxAs26136
	for sip@lists.bell-labs.com; Tue, 16 Jan 2001 10:59:10 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: sip@lists.bell-labs.com
Subject: Re: [SIP] Early media replacement.
Message-ID: <20010116105905.A22043@fdd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 10:59:05 -0600

----- Forwarded message from Rick Dean <siplist@fdd.com> -----

Date: Tue, 16 Jan 2001 10:58:05 -0600
From: Rick Dean <siplist@fdd.com>
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Subject: Re: [SIP] Early media replacement.
In-Reply-To: <B65B4F8437968F488A01A940B21982BF9AB0D8@DYN-EXCH-001.dynamicsoft.com>; from jdrosen@dynamicsoft.com on Tue, Jan 16, 2001 at 01:34:26AM -0500

On Tue, Jan 16, 2001 at 01:34:26AM -0500, Jonathan Rosenberg wrote:
> 
> 
> > -----Original Message-----
> > From: Rick Dean [mailto:siplist@fdd.com]
> > Sent: Tuesday, January 09, 2001 11:20 AM
> > To: Jonathan Rosenberg
> > Cc: sip@lists.bell-labs.com
> > Subject: Re: [SIP] Early media replacement.
> > 
> > 
> > On Tue, Jan 09, 2001 at 01:25:41AM -0500, Jonathan Rosenberg wrote:
> > > In practice, I doubt calls to PSTN numbers will fork anyway. 
> > 
> > Then why do you oppose me?  
> 
> Because I do not believe forking is the only aspect of this issue.

Unspecified aspects?  

> > 
> > PSTN interoperability is paramount to me.  
> > Unfortunately, my calls need to work better 
> > than 99% of the time.  
> > 
> > If gateways "need to send media 
> > in the reverse direction without knowing what 
> > it is", then they should send a 200 OK because
> > the forking won't work anyway.  Why else
> > should early media persist if not for
> > forking? 
> 
> Because always sending a 200 OK has implications
> for services on the SIP side. For example, it completely
> eliminates the possibility of a call forward busy or 
> call forward no answer. This is the reason why the two
> phase INVITE in the original DCS proposal was so disliked - 
> it changed the fundamental notion of what sending a 200 OK
> meant. 

Sure, if a gateway knows the far end is busy, it should send
a 486 busy -- no debate.  If the gateway has unknown progress media 
which might be busy-tone, ringback, or voice prompting; sending 200 
OK helps manage the audio channel.   Do you expect the human to 
hit a key on busy tone so his UA sends a CANCEL?  or should 
he just know to wait?

I regret the 200 OK notion.  With audio, I argue a session
is established.  As a call originating UA, how to I suspend or 
redirect the early media if my INVITE won't complete?

Sorry to be such as pain on this subject.

--
Rick
rick_dean@3com.com

> 
> >  Hopefully, the gateway builders will 
> > do the right thing.
> 
> Its not a question of lazy implementations. Its a question of not having
> enough
> information to send anything but early media.
> 
> > Let's depreciate early media.
> 
> Lets stop making broad, sweeping statements about the directions to go in,
> and rather analyze the problem so we can arrive at a proper conclusion.
> 
> -Jonathan R.
> 
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com

----- End forwarded message -----

_______________________________________________
"This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip
to subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body"


From sip-admin@lists.bell-labs.com  Tue Jan 16 12:13:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16675
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 12:13:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 024FA44358; Tue, 16 Jan 2001 11:14:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id B05DB44374
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 11:13:14 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0GHD2S05930;
	Tue, 16 Jan 2001 11:13:02 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Media after INVITE
Message-ID: <20010116111257.A5777@fdd.com>
References: <3A63F0E3.459BA9E7@lmf.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A63F0E3.459BA9E7@lmf.ericsson.se>; from christer.holmberg@lmf.ericsson.se on Tue, Jan 16, 2001 at 08:57:39AM +0200
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 11:12:57 -0600

On Tue, Jan 16, 2001 at 08:57:39AM +0200, Christer Holmberg wrote:
> 
> Hi,
> 
> I was reading the thread about Early media replacement. My question,
> however, has not so much to do with the 183-to-be-or-not-to-be, but
> rather with the requirement that a UA should be able to receive media
> after the first INVITE is sent. This mean that the remote user wouldn't
> have to send any response at all - instead he could start sending media
> and would never be charged for it. Yes, the re-transmission timer for
> the INVITE will expire, and the call will be dropped, but until that the
> remote party have plenty of time to send media to the caller (even if
> it's only one-way, it can be a news service/weather service/ voice mail/
> whatever, where two-way direction is not needed).

200 OK need not be tied to billing.  In typical phone systems each
device creates a call detail record (CDR) which contains more 
information and is used for billing.  For this example the gateway
CDR would probably be relied upon.

Some systems like AT&T cell phones charge for ringback.  Maybe
SIP gateway service will write their contracts similarly.  The
ringback need not be sent as RTP.

Yes, some interactive voice response (IVR) servers use this
technique to "steal" service.

--
Rick
rick_dean@3com.com

> 
> My opinion is that SOME response (183, 200, or whatever will be decided
> upon) should be received before the UA is required to start receiving
> media. I know that we then can get some other issues, ie. if it takes a
> long time for the 200 response to reach the caller the first RTP media
> packets will be lost. But, again, at least the caller (or a possible
> intermediate proxy handling charging) will know that the media can be
> sent.
> 
> This doesn't solve the issue about getting media streams from different
> locations, but at least we would know when we should expect to receive
> media in the first place.
> 
> This issue may have been discussed before, so I appologise if I'm
> bringing it up again...
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
Content-Description: Card for Christer Holmberg


_______________________________________________
"This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip
to subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body"


From sip-admin@lists.bell-labs.com  Tue Jan 16 12:20:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16915
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 12:20:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D1D4444387; Tue, 16 Jan 2001 11:21:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cisco.com (jindo.cisco.com [171.69.11.73])
	by lists.bell-labs.com (Postfix) with ESMTP id 955BB44398
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 11:08:48 -0500 (EST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id JAA12172;
	Tue, 16 Jan 2001 09:08:36 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA23920; Tue, 16 Jan 2001 09:08:35 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14948.32787.751400.408672@thomasm-u1.cisco.com>
To: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
Cc: sip@lists.bell-labs.com
Subject: [SIP] Media after INVITE
In-Reply-To: <3A63F0E3.459BA9E7@lmf.ericsson.se>
References: <3A63F0E3.459BA9E7@lmf.ericsson.se>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 09:08:35 -0800 (PST)
Content-Transfer-Encoding: 7bit

Christer Holmberg writes:
 > 
 > Hi,
 > 
 > I was reading the thread about Early media replacement. My question,
 > however, has not so much to do with the 183-to-be-or-not-to-be, but
 > rather with the requirement that a UA should be able to receive media
 > after the first INVITE is sent. This mean that the remote user wouldn't
 > have to send any response at all - instead he could start sending media
 > and would never be charged for it. Yes, the re-transmission timer for
 > the INVITE will expire, and the call will be dropped, but until that the
 > remote party have plenty of time to send media to the caller (even if
 > it's only one-way, it can be a news service/weather service/ voice mail/
 > whatever, where two-way direction is not needed).

I believe that this is an appeal to put the best
effort genie back in the bottle. Namely, unless
there is some way to prevent two cooperating
parties from sending traffic to one another
(firewall, elevated qos), early media is the least
of your worries. I could just as easily send you a
mail message with an SDP announcement and
circumvent your biller, after all.

 > My opinion is that SOME response (183, 200, or whatever will be decided
 > upon) should be received before the UA is required to start receiving
 > media. I know that we then can get some other issues, ie. if it takes a
 > long time for the 200 response to reach the caller the first RTP media
 > packets will be lost. But, again, at least the caller (or a possible
 > intermediate proxy handling charging) will know that the media can be
 > sent.

It seems to me that the UAC can do whatever it
feels like to the media stream, including
dropping it on the floor, so is this really
a protocol issue?

		Mike

_______________________________________________
"This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip
to subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body"


From sip-admin@lists.bell-labs.com  Tue Jan 16 12:24:07 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16986
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 12:24:07 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8219B4439F; Tue, 16 Jan 2001 11:24:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by lists.bell-labs.com (Postfix) with ESMTP id E023B4439E
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 11:23:14 -0500 (EST)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600);
	 Tue, 16 Jan 2001 09:22:13 -0800
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 16 Jan 2001 09:22:57 -0800 (Pacific Standard Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532);
	 Tue, 16 Jan 2001 09:22:57 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0
content-class: urn:content-classes:message
Subject: RE: [SIP] Media after INVITE
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Message-ID: <CC2E64D4B3BAB646A87B5A3AE97090420EFAD9FC@speak.dogfood>
Thread-Topic: [SIP] Media after INVITE
Thread-Index: AcB/ifJq+1QiKURIS/y9guPXk+VIWgAVX4Xw
From: "Christian Huitema" <huitema@exchange.microsoft.com>
To: "Christer Holmberg" <christer.holmberg@lmf.ericsson.se>,
        <sip@lists.bell-labs.com>
X-OriginalArrivalTime: 16 Jan 2001 17:22:57.0197 (UTC) FILETIME=[F7BA7DD0:01C07FE0]
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 09:22:56 -0800
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA16986

> I was reading the thread about Early media replacement. My question,
> however, has not so much to do with the 183-to-be-or-not-to-be, but
> rather with the requirement that a UA should be able to receive media
> after the first INVITE is sent. This mean that the remote 
> user wouldn't
> have to send any response at all - instead he could start 
> sending media
> and would never be charged for it. 

Well, this is very much a fact of life. The moment you publish the RTP
address and port of the caller, anyone that get that address can start 
sending packets to it. Whether the packet are voiced out or dropped on
the floor depends on the caller. Presumably, if the caller is party
in a conspiracy to avoid taxes, the packets will not be dropped.

> My opinion is that SOME response (183, 200, or whatever will 
> be decided
> upon) should be received before the UA is required to start receiving
> media. I know that we then can get some other issues, ie. if 
> it takes a
> long time for the 200 response to reach the caller the first RTP media
> packets will be lost. But, again, at least the caller (or a possible
> intermediate proxy handling charging) will know that the media can be
> sent.

Well, merely sending a response does not achieve that. You only know
that the
caller is ready to receive packets if the caller tells you so. There are

basically two ways: after receiving the INVITE, or after receiving the 
ACK. Analysis of phone gateways shows that if the caller is not ready to
receive 
before the ringing or the announcement starts, i.e. after the INVITE in
the
current call flows, then some packets will be lost. 

To change that, you have to revise the call flows for phone
connections, so that there is a complete 3 ways handshake before you
start
propagating the call on the phone network. Sort of "receive INVITE, send
progress asking for permission to send early media, receive ack, then
and only then
start ringing the phone." 

Indeed, such a 3-ways handshake automatically precludes ringing several
destinations
at the same time.

-- Christian Huitema

_______________________________________________
"This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip
to subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body"


From sip-admin@lists.bell-labs.com  Tue Jan 16 12:31:40 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17123
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 12:31:40 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BA28444390; Tue, 16 Jan 2001 11:31:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16])
	by lists.bell-labs.com (Postfix) with ESMTP id DD8784438B
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 11:30:49 -0500 (EST)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260)
 id <0G7900J01N6QSX@firewall.mcit.com> for sip@lists.bell-labs.com; Tue,
 16 Jan 2001 17:28:02 +0000 (GMT)
Received: from dgismtp04.wcomnet.com ([166.38.58.144])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0G7900FLXN6QYH@firewall.mcit.com> for sip@lists.bell-labs.com;
 Tue, 16 Jan 2001 17:28:02 +0000 (GMT)
Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262)
 id <0G7900201N6QFB@dgismtp04.wcomnet.com> for sip@lists.bell-labs.com; Tue,
 16 Jan 2001 17:28:02 +0000 (GMT)
Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0G7900101N5HZU@dgismtp04.wcomnet.com> for
 sip@lists.bell-labs.com; Tue, 16 Jan 2001 17:28:01 +0000 (GMT)
Received: from omzexch007.mcit.com ([166.37.194.38])
 by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0G790013WN5FGC@dgismtp04.wcomnet.com> for
 sip@lists.bell-labs.com; Tue, 16 Jan 2001 17:27:15 +0000 (GMT)
Received: by omzexch007 with Internet Mail Service (5.5.2651.58)
 id <CSGVD5SW>; Tue, 16 Jan 2001 17:27:15 +0000
Content-return: allowed
From: "Ngo, Dai" <c-Dai.Ngo@WCOM.Com>
To: sip@lists.bell-labs.com
Message-id: <492EB4A3F68CD411ABE800508B69362E11C490@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_vz73XTxsAJx67yMjT+2eEg)"
Subject: [SIP] Event Header Token for Presence and InstanT Message
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 17:27:14 +0000

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.

--Boundary_(ID_vz73XTxsAJx67yMjT+2eEg)
Content-type: text/plain; charset=ISO-8859-1

Hi all,

On page 9 of Draft-Roach-Sip-Subscribe-Notify-02.txt stated that "The Event
header is considered mandatory...However, to maintain compatibility with
PINT servers may interpret a SUBSCRIBE request with no "Event" header as
requesting a subscription to PINT events. If the servers do not support
PINT, they should instead return "400 Bad Request"".

Currently the Event header is not mentioned in the Presence/Instant Message
drafts. How do we support Presence and Instant Message then?

Thanks,

Dai Ngo


--Boundary_(ID_vz73XTxsAJx67yMjT+2eEg)
Content-type: text/html; charset=ISO-8859-1
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=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>Event Header Token for Presence and InstanT Message</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi all,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">On page 9 of =
Draft-Roach-Sip-Subscribe-Notify-02.txt stated that &quot;The Event =
header is considered mandatory...However, to maintain compatibility =
with PINT servers may interpret a SUBSCRIBE request with no =
&quot;Event&quot; header as requesting a subscription to PINT events. =
If the servers do not support PINT, they should instead return =
&quot;400 Bad Request&quot;&quot;.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Currently the Event header is not =
mentioned in the Presence/Instant Message drafts. How do we support =
Presence and Instant Message then?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Dai Ngo</FONT>
</P>

</BODY>
</HTML>

--Boundary_(ID_vz73XTxsAJx67yMjT+2eEg)--

_______________________________________________
"This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip
to subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body"


From sip-admin@lists.bell-labs.com  Tue Jan 16 12:40:20 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17259
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 12:40:19 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A2ACC44383; Tue, 16 Jan 2001 11:38:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id B64B044336
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 11:37:32 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0GHbMc23204
	for sip@lists.bell-labs.com; Tue, 16 Jan 2001 11:37:22 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: sip@lists.bell-labs.com
Subject: Re: [SIP] Back-to-back UAs
Message-ID: <20010116113721.A26496@fdd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 11:37:21 -0600


Keith,

I apologize.  Back-to-back UA is another name for Rosenberg's
3rd Party Call Control.  3PCC was first published here..
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenberg-sip-3pcc-00.txt
The draft does not use the B2BUA moniker.

Yes, 3PCC/B2BUA can break the end to end nature.  Sometimes this
is desired.  A company may wish to hide its internal
routing.  A fragile gateway may need a SIP wrapper/firewall.  etc.

The biggest problem I currently experience is 
looping.  I wish all B2BUAs would preserve 
the call-id.  Unfortunately, I can't get rid of my biggest
B2BUA, the public switched telephony network (PSTN).  :-/

--
Rick
rick_dean@3com.com

On Tue, Jan 16, 2001 at 12:57:05PM -0000, Drage, Keith (Keith) wrote:
> I keep seeing mention of back-to-back UAs and I think I understand what is
> trying to be done with them. 
> 
> I do however see an issue that there is apparently no documentation of this
> concept in any draft. Therefore it leads to the question of when does a
> proxy become a back-to-back UA, and therefore perform all error handling and
> syntactic checking as a UA rather than a proxy. Because there is no mention
> in any draft, it would probably never be identified in any conformance
> statement, and an attaching UA to this concept might therefore see behaviour
> that was not expected.
> 
> I also see problems where, because it is not documented, the impact of
> interactions with other drafts may not have been assessed. For example, is
> there an impact on the privacy draft, such that the identifiers passed using
> the concepts of the privacy draft will never pass the back-to-back UA? Do we
> have problems with any headers that have been ciphered, because we do not
> wish to release them outside proxies?
> 
> I would therefore ask, if such a concept is meant to legally exist, should
> be not at least define it somewhere. (Thats assuming I haven't missed it
> somewhere!)
> 
> Keith Drage
> Keith Drage
> Lucent Technologies
> Tel: +44 1793 776249
> Email: drage@lucent.com
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

----- End forwarded message -----

_______________________________________________
"This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip
to subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body"


From sip-admin@lists.bell-labs.com  Tue Jan 16 13:55:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19407
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 13:55:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D02F44433C; Tue, 16 Jan 2001 12:56:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id CAE8F44336
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 12:55:02 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA20380;
	Tue, 16 Jan 2001 13:50:05 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KH9KZ>; Tue, 16 Jan 2001 13:44:07 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BFB97FF9@DYN-EXCH-001.dynamicsoft.com>
From: Igor Slepchin <ISlepchin@dynamicsoft.com>
To: "'Sekhar Banerjee'" <SBanerjee@lboard.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Presence of * in Contact Header
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 13:44:06 -0500

I don't think there is an ambiguity here: a Contact consisting of a _sole_
"*" character has that special meaning; the "*" in the Contact below is part
of display name, which allows "*" characters.

---
Igor Slepchin


> -----Original Message-----
> From: Sekhar Banerjee [mailto:SBanerjee@lboard.com]
> Sent: Tuesday, January 16, 2001 12:48 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Presence of * in Contact Header
> 
> 
> Hi All,
> 	I would like to get a consensus on this issue from the SIP
> implementors on this list. Is the contact header
> 	
> Contact:	*69 <sip:123456@10.1.2.2:5060>
> 	
> 	a valid contact header. I have had one side say that 
> since the * has
> a special meaning in the Contact header and hence there 
> shouldnt be anything
> else in that header. The other opinion is that since
> the Contact Header contains more than the * hence there isnt 
> anything wrong
> with it and the stack should parse it all.
> 	What is the correct way of handling this ?
> 
> 
> Thanks
> 
> Sekhar Banerjee
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
"This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip
to subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body"


From sip-admin@lists.bell-labs.com  Tue Jan 16 14:22:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19929
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 14:22:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A3E564434F; Tue, 16 Jan 2001 13:23:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 764C24433C
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 13:22:37 -0500 (EST)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA07239;
	Tue, 16 Jan 2001 11:22:33 -0800 (PST)
Received: from sony-laptop (rmahy-dsl5.cisco.com [10.19.53.126])
	by imop.cisco.com (Mirapoint)
	with SMTP id AAH38546;
	Tue, 16 Jan 2001 11:22:20 -0800 (PST)
Message-Id: <4.1.20010116110239.00b3cc50@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
To: Neil Deason <ndeason@ubiquity.net>
From: Rohan Mahy <rohan@cisco.com>
Subject: Re: [SIP] Need rough count for interim meeting
Cc: sip@lists.bell-labs.com
In-Reply-To: <3A6462F9.9977649@ubiquity.net>
References: <5.0.0.25.2.20010115114451.0245cc60@imop.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 11:28:28 -0800

Hi,

We will discuss lots of open in addition to the REFER issues mentioned on
the list.  Since we are going all day on Feb 8th and 9th (including the
evening of the 8th) some of the time will be inherently inconvenient for
folks outside the Americas. 

Below is the sample agenda I sent to the chairs.  Hopefully you can call in
for the base spec open issues and firewall disucssion.

thanks,
-rohan

All times in Central Standard Time (UTC minus 6 hours)
There will be lots of short breaks for drinks, snacks, and sanity
>Thursday Feb 8th
>08:00  Logisitics and Agenda Bashing
>08:30  SUBSCRIBE/NOTIFY (split with presence docs, forking)
>11:00  Call Control Models (3pcc vs. phonectl vs. peer-to-peer 3pcc)
>12:30  Break for Lunch (provided)
>13:30  REFER issues
>16:30  SIP device configuration
>17:30  Dinner
>19:00  SIP conferencing
>21:00  Stop for the night
>
>Friday Feb 9th
>08:00  Base spec open issues: (Record Routing, Early Media, ...)
>12:00  Break for Lunch (provided)
>13:00  Firewall/NAT traversal
>15:00  AAA requirements
>17:00  Close


At 07:04 AM 1/16/01 , Neil Deason wrote:
>Is there a decision on whether to discuss more open issues than 
>REFER? If so is there an agenda available? Can we also make
>the time convenient for people outside the US.
>
>Cheers,
>Neil.
>-- 
>Ubiquity Software Corporation, UK        http://www.ubiquity.net
>
>Rohan Mahy wrote:
>> 
>> Hi,
>> 
>> I need a rough count of those attending in person and by phone, so I can
>> reserve the rooms / conference bridge, etc..
>> 
>> Please reply privately to me (or click on the links below) and I will post
>> a count back to the list.
>>         mailto:rohan@cisco.com?subject=AttendingInterimSIPmeeting
>> 
>>         mailto:rohan@cisco.com?subject=CallingInterimSIPmeeting


_______________________________________________
"This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip
to subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body"


From sip-admin@lists.bell-labs.com  Tue Jan 16 17:02:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22433
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 17:02:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BEC5F4433C; Tue, 16 Jan 2001 16:03:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from calxch01.clarent.com (64-60-54-195-cust.telepacific.net [64.60.54.195])
	by lists.bell-labs.com (Postfix) with ESMTP id 6236A44336
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 16:02:55 -0500 (EST)
Received: by CALXCH01 with Internet Mail Service (5.5.2653.19)
	id <Y57CMXKK>; Tue, 16 Jan 2001 14:02:30 -0800
Received: from rwcjfmule01 (host114-111.cablelabs.com [192.160.73.114]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id C5XRAKJ0; Tue, 16 Jan 2001 14:01:23 -0800
Reply-To: <jfmule@clarent.com>
From: "Jean-Francois Mule" <jfmule@clarent.com>
To: <sip@lists.bell-labs.com>
Cc: <klingle@cisco.com>, "'Joon Maeng'" <joon_maeng@vtel.com>,
        "'Dave Walker'" <drwalker@ss8networks.com>
Subject: [SIP] Keeping paragraph numbering in 2543bis-02 consistent with RFC2543?
Message-ID: <00c801c08007$d894ca10$0100007f@rwcjfmule01>
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 CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <000a01c07f11$da219760$5d8e6b80@cisco.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 14:01:13 -0800
Content-Transfer-Encoding: 7bit

The current draft of 2543bis does not keep the same paragraph numbering as
2543.

While this is a very minor editorial comment, it might become an issue for
some I-D/upcoming rfcs whose paragraph references are going to be outdated
as soon as 2543bis gets published.  This will cause numerous unnecessary
editorial updates, in particular, for the sip protocol mib:  many MIB
objects reference specific sections of 2543 (for e.g. organization header
definition, section 10.4 now 10.2 on retry timers and counters, ...).  This
might cause the unecessary revision of many MIB object REFERENCE down the
road...

Let alone the fact that many are working with bis these days and when a
reference pops up, it is a pain.
Comments? Any suggestions of what document to reference in the next rev of
the SIP MIB I-D (the outdated but published RFC 2543 or the current internet
draft 2543bis-02)?

Jean-Francois Mule

_______________________________________________
"This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip
to subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body"


From sip-admin@lists.bell-labs.com  Tue Jan 16 18:24:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23280
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 18:24:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6A22B4433C; Tue, 16 Jan 2001 17:25:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj_ntserver3.sj.nuera.com (h-207-20-110-62.ncal.verio.net [207.20.110.62])
	by lists.bell-labs.com (Postfix) with ESMTP id 96C4944336
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 17:24:30 -0500 (EST)
Received: by sj_ntserver3.sj.nuera.com with Internet Mail Service (5.5.2650.21)
	id <CWGVGJB3>; Tue, 16 Jan 2001 15:24:18 -0800
Message-ID: <DD70FD1C981BD411B64400508BA547C1049E0A@sj_ntserver3.sj.nuera.com>
From: "Emami-Nouri, Mohsen" <memami@nuera.com>
To: "'Rosen, Brian'" <Brian.Rosen@marconi.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Changes to List Policy
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 15:24:07 -0800

should we ignore Jonathan's email from 01/07/01 introducing a different list
for SIP implementers ( simple@mailman.dynamicsoft.com )

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@marconi.com]
Sent: Tuesday, January 16, 2001 8:26 AM
To: sip@lists.bell-labs.com
Subject: [SIP] Changes to List Policy


As you all know, the sip list is very high volume.
To try to ease difficulties for many list members, we are going to
move "newbie" type questions, questions that ask how something
already an RFC (or about to be) works, from this list to the
sip-implementor's list.  This list will be the place that
we discuss new protocol development.

Both lists remain unmoderated.  Anyone is free to subscribe to either, 
or both, lists.  We can't stop inappropriate postings, but the 
chairs will try to cut off discussion on this list, and move it
to the sip-implementors list if it covers existing SIP.  I have
assurances from most of our more prolific assistance providers 
that they ARE subscribed to the sip-implementors list, and they 
WILL continue to provide assistance on that list, as they do here.  
I urge those of you who we have not spoken to, but also provide 
this essential service to continue to do so on the sip-implementors 
list.

To subscribe to sip-implementors, send mail to 
majordomo@cs.columbia.edu with "subscribe sip-implementors" 
in the body

Thanks

Brian

_______________________________________________
"This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip
to subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body"

_______________________________________________
"This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip
to subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body"


From sip-admin@lists.bell-labs.com  Tue Jan 16 20:20:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24721
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 20:20:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E3BD94433C; Tue, 16 Jan 2001 19:21:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 67FC244336
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 19:20:53 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA07273;
	Tue, 16 Jan 2001 20:20:32 -0500 (EST)
Message-ID: <3A64F360.AD5C9B4A@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
Cc: "'Keith Robinson'" <Keith.Robinson@marconi.com>, sip@lists.bell-labs.com,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Subject: Re: Outbound Proxies Renewed (was [SIP] Proxy Routing Logic)
References: <E79883AEA37FD411A58C00508BAC5F4B2B5C73@exchange1.nuera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 20:20:32 -0500
Content-Transfer-Encoding: 7bit

> "Fairlie-Cuninghame, Robert" wrote:
> 

> I would also like to reiterate Jonathan's design goals for a
> solutions: that a proxy should not need to know whether it is being
> used as an outbound proxy or have to take special action when being
> used as a outbound proxy. The UA should be responsible for taking any
> action required (given that the UA is the only entity that knows
> whether it using a proxy as an "outbound proxy").

Before we get into details, I want to make sure we don't forget that
proxy servers can also use outbound proxies, not just UAs. 



-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 16 20:37:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24878
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 20:37:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 269C444374; Tue, 16 Jan 2001 19:38:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by lists.bell-labs.com (Postfix) with ESMTP id 2F07544372
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 19:37:21 -0500 (EST)
Received: from fokus.gmd.de (dhcp012 [195.37.78.140])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id CAA26304;
	Wed, 17 Jan 2001 02:36:58 +0100 (MET)
Message-ID: <3A64F731.7526FF9B@fokus.gmd.de>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Organization: GMD Fokus
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Emami-Nouri, Mohsen" <memami@nuera.com>
Cc: "'Rosen, Brian'" <Brian.Rosen@marconi.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] Changes to List Policy
References: <DD70FD1C981BD411B64400508BA547C1049E0A@sj_ntserver3.sj.nuera.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 02:36:49 +0100
Content-Transfer-Encoding: 7bit

There are three separate mailing lists:
- SIP Instant Messaging & Presence ML ( which is the simple@mailman.dynamicsoft.com 
- SIP WG's ML
- SIP implementors ML, to which "newbie issues" were moved recently

Jiri

"Emami-Nouri, Mohsen" wrote:
> 
> should we ignore Jonathan's email from 01/07/01 introducing a different list
> for SIP implementers ( simple@mailman.dynamicsoft.com )

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 16 21:34:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26370
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 21:34:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B53294433C; Tue, 16 Jan 2001 20:35:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 7C79544336
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 20:34:06 -0500 (EST)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <CKD5P83Z>; Tue, 16 Jan 2001 18:33:52 -0800
Message-ID: <E79883AEA37FD411A58C00508BAC5F4B2B5C75@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'Keith Robinson'" <Keith.Robinson@marconi.com>, sip@lists.bell-labs.com,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Subject: RE: Outbound Proxies Renewed (was [SIP] Proxy Routing Logic)
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0802D.EADC8CA0"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 16 Jan 2001 18:33:46 -0800

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_01C0802D.EADC8CA0
Content-Type: text/plain;
	charset="iso-8859-1"

Yes I agree Henning. In fact, that was one of the reasons I believe that
Keith's first option (a) [ie, the UA/proxy removing the next Route header
even if it doesn't route to it] is a risky idea. I think you may run into
problems when you get chains of outbound proxies, etc UA sends to outbound
proxy which in turn sends to another outbound proxy. In my mind the Route is
better left in place until it is actually used.

Cheers,

Robert.

-- My opinions are my own and should not be taken as representing those of
Nuera Communications, Inc. -- 

		-----Original Message-----
		From:	Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
		Sent:	Wednesday, January 17, 2001 12:21 PM
		To:	Fairlie-Cuninghame, Robert
		Cc:	'Keith Robinson'; sip@lists.bell-labs.com; Jonathan
Rosenberg
		Subject:	Re: Outbound Proxies Renewed (was [SIP]
Proxy Routing Logic)

		> "Fairlie-Cuninghame, Robert" wrote:
		> 

		> I would also like to reiterate Jonathan's design goals for
a
		> solutions: that a proxy should not need to know whether it
is being
		> used as an outbound proxy or have to take special action
when being
		> used as a outbound proxy. The UA should be responsible for
taking any
		> action required (given that the UA is the only entity that
knows
		> whether it using a proxy as an "outbound proxy").

		Before we get into details, I want to make sure we don't
forget that
		proxy servers can also use outbound proxies, not just UAs. 



		-- 
		Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

------_=_NextPart_001_01C0802D.EADC8CA0
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Outbound Proxies Renewed (was [SIP] Proxy Routing =
Logic)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Yes I agree Henning. In fact, that was =
one of the reasons I believe that Keith's first option (a) [ie, the =
UA/proxy removing the next Route header even if it doesn't route to it] =
is a risky idea. I think you may run into problems when you get chains =
of outbound proxies, etc UA sends to outbound proxy which in turn sends =
to another outbound proxy. In my mind the Route is better left in place =
until it is actually used.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Robert.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- My opinions are my own and should =
not be taken as representing those of Nuera Communications, Inc. -- =
</FONT>
</P>
<UL><UL>
<P><A NAME=3D"_MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original =
Message-----</FONT></A>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:&nbsp;&nbsp; Henning G. =
Schulzrinne [<A =
HREF=3D"mailto:hgs@cs.columbia.edu">mailto:hgs@cs.columbia.edu</A>]</FON=
T></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D2 FACE=3D"Arial">Wednesday, January 17, 2001 12:21 PM</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">Fairlie-Cuninghame, Robert</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">'Keith Robinson'; sip@lists.bell-labs.com; Jonathan =
Rosenberg</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D2 FACE=3D"Arial">Re: Outbound Proxies Renewed (was =
[SIP] Proxy Routing Logic)</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; &quot;Fairlie-Cuninghame, =
Robert&quot; wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; I would also like to reiterate =
Jonathan's design goals for a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; solutions: that a proxy should =
not need to know whether it is being</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; used as an outbound proxy or =
have to take special action when being</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; used as a outbound proxy. The UA =
should be responsible for taking any</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; action required (given that the =
UA is the only entity that knows</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; whether it using a proxy as an =
&quot;outbound proxy&quot;).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Before we get into details, I want to =
make sure we don't forget that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">proxy servers can also use outbound =
proxies, not just UAs. </FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Henning Schulzrinne&nbsp;&nbsp; <A =
HREF=3D"http://www.cs.columbia.edu/~hgs" =
TARGET=3D"_blank">http://www.cs.columbia.edu/~hgs</A></FONT>
</P>
</UL></UL>
</BODY>
</HTML>
------_=_NextPart_001_01C0802D.EADC8CA0--

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 16 23:26:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29601
	for <sip-archive@odin.ietf.org>; Tue, 16 Jan 2001 23:26:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 25F544433C; Tue, 16 Jan 2001 22:27:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb19.rediffmail.com (unknown [203.199.83.143])
	by lists.bell-labs.com (Postfix) with SMTP id 2327744336
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 22:26:35 -0500 (EST)
Received: (qmail 24840 invoked by uid 510); 17 Jan 2001 04:19:30 -0000
Message-ID: <20010117041930.24839.qmail@mailweb19.rediffmail.com>
Received: from unknown (203.197.231.18) by rediffmail.com via HTTP; 17 Jan 2001 04:19:30 -0000
MIME-Version: 1.0
To: "jdrosen@dynamicsoft.com" <jdrosen@dynamicsoft.com>,
        "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
Subject:  Re: RE: [SIP] OPTIONS method, bug in draft-ietf-sip-rfc2543bis-02
From: "Deepak  Mohan" <deepakwarrier@rediffmail.com>
Content-ID: <Wed_Jan_17_09_49_30_IST_2001_0@mailweb19.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 17 Jan 2001 04:19:30 -0000
Content-Transfer-Encoding: 7bit

> In table 4 and 5 of draft-ietf-sip-rfc2543bis-02, the OPTIONS 
> message cannot have the "Expires" or the "Priority" headers.
> 
> Couldn't the "Expires" header be used to *check* if a call 
> can be established using OPTIONS, within the specified time?

THis is not the meaning of expires. As a general header, it refers to the
amount of time for which the request is valid. That is not the same thing as
the amount of time over which a call from the same party would be
acceptable.

What I meant to ask was, can OPTIONS with an "Expires" of say, "some_date", can be used to check if another request (INVITE), will reach the target UAS with the "Expires" value also set to "some_date". This might be useful if you want a call to be setup within a certain duration of receiving a command from a user to setup a call.

Thanks,
Deepak

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 00:24:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00582
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 00:24:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 863CE4433C; Tue, 16 Jan 2001 23:25:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb15.rediffmail.com (unknown [203.199.83.23])
	by lists.bell-labs.com (Postfix) with SMTP id 9DB7544336
	for <sip@lists.bell-labs.com>; Tue, 16 Jan 2001 23:24:57 -0500 (EST)
Received: (qmail 14158 invoked by uid 510); 17 Jan 2001 05:17:33 -0000
Message-ID: <20010117051733.14157.qmail@mailweb15.rediffmail.com>
Received: from unknown (203.197.178.11) by rediffmail.com via HTTP; 17 Jan 2001 05:17:33 -0000
MIME-Version: 1.0
To: "vkg@lucent.com" <vkg@lucent.com>
Subject:  Re: [SIP] REGISTER requests
Cc: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
From: "Vijeth  D" <vijethd@rediffmail.com>
Content-ID: <Wed_Jan_17_10_47_32_IST_2001_0@mailweb15.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 17 Jan 2001 05:17:33 -0000
Content-Transfer-Encoding: 7bit




> How will the REGISTRAR find the IP address corresponding to the SIPURL 
> being registered

>Contact header.  All this is included in the RFC as well.
 
If the contact header is a SIPURL without IP addres i.e with user@host or user@domain, does it mean these SIPURLs in the contact header should be registered before?
OR does it mean that the contact header should have a IP address?

Vijeth


_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 01:31:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04056
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 01:31:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6350C4433C; Wed, 17 Jan 2001 00:32:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 5E0D644336
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 00:31:04 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA27850;
	Wed, 17 Jan 2001 01:33:30 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9K2AF3>; Wed, 17 Jan 2001 01:27:31 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB0F6@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Emami-Nouri, Mohsen'" <memami@nuera.com>,
        "'Rosen, Brian'" <Brian.Rosen@marconi.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Changes to List Policy
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 01:27:30 -0500



 

> -----Original Message-----
> From: Emami-Nouri, Mohsen [mailto:memami@nuera.com]
> Sent: Tuesday, January 16, 2001 6:24 PM
> To: 'Rosen, Brian'; sip@lists.bell-labs.com
> Subject: RE: [SIP] Changes to List Policy
> 
> 
> should we ignore Jonathan's email from 01/07/01 introducing a 
> different list
> for SIP implementers ( simple@mailman.dynamicsoft.com )

This list is *NOT* for sip implementors.

It is for discussion of the sip for presence and IM drafts, for which we are
in the process of forming a separate working group.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 01:39:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04943
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 01:39:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6A57444389; Wed, 17 Jan 2001 00:40:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 7545544349
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 00:39:20 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA27879;
	Wed, 17 Jan 2001 01:41:56 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9K2AFV>; Wed, 17 Jan 2001 01:35:57 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB0F8@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'jfmule@clarent.com'" <jfmule@clarent.com>, sip@lists.bell-labs.com
Cc: klingle@cisco.com, "'Joon Maeng'" <joon_maeng@vtel.com>,
        "'Dave Walker'" <drwalker@ss8networks.com>
Subject: RE: [SIP] Keeping paragraph numbering in 2543bis-02 consistent wi
	th RFC2543?
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 01:35:56 -0500

The SIP MIB should reference rfc2543. When it revs to an RFC, we should rev
the MIB if needed. MIBs should always reference RFCs.

We are planning a significant rewrite of the SIP spec to improve readability
and completeness. This will make it impossible to maintain section and
paragraph references.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

> -----Original Message-----
> From: Jean-Francois Mule [mailto:jfmule@clarent.com]
> Sent: Tuesday, January 16, 2001 5:01 PM
> To: sip@lists.bell-labs.com
> Cc: klingle@cisco.com; 'Joon Maeng'; 'Dave Walker'
> Subject: [SIP] Keeping paragraph numbering in 2543bis-02 
> consistent with
> RFC2543?
> 
> 
> The current draft of 2543bis does not keep the same paragraph 
> numbering as
> 2543.
> 
> While this is a very minor editorial comment, it might become 
> an issue for
> some I-D/upcoming rfcs whose paragraph references are going 
> to be outdated
> as soon as 2543bis gets published.  This will cause numerous 
> unnecessary
> editorial updates, in particular, for the sip protocol mib:  many MIB
> objects reference specific sections of 2543 (for e.g. 
> organization header
> definition, section 10.4 now 10.2 on retry timers and 
> counters, ...).  This
> might cause the unecessary revision of many MIB object 
> REFERENCE down the
> road...
> 
> Let alone the fact that many are working with bis these days 
> and when a
> reference pops up, it is a pain.
> Comments? Any suggestions of what document to reference in 
> the next rev of
> the SIP MIB I-D (the outdated but published RFC 2543 or the 
> current internet
> draft 2543bis-02)?
> 
> Jean-Francois Mule
> 
> _______________________________________________
> "This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip
> to subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body"
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 03:08:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA14515
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 03:08:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C9D054433C; Wed, 17 Jan 2001 02:09:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id 9CC6544336
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 02:08:36 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f0H88Nd01445
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 09:08:23 +0100 (MET)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.38])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id KAA05263
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 10:08:22 +0200 (EET)
Message-ID: <3A6552F4.4DD36BC3@lmf.ericsson.se>
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: multipart/mixed;
 boundary="------------14AF99F6E08B29CE44A1BC65"
Subject: [SIP] Interim Meeting
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 10:08:20 +0200

This is a multi-part message in MIME format.
--------------14AF99F6E08B29CE44A1BC65
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

Sorry if I've missed it, but what will the location (address etc.) of
the meeting be? It is needed to find a nearby hotel.

Regards,

Christer Holmberg
Ericsson Finland
--------------14AF99F6E08B29CE44A1BC65
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------14AF99F6E08B29CE44A1BC65--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 04:16:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14894
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 04:16:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E36384433C; Wed, 17 Jan 2001 03:17:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb5.rediffmail.com (unknown [202.54.124.150])
	by lists.bell-labs.com (Postfix) with SMTP id 3C8AF44336
	for <Sip@lists.bell-labs.com>; Wed, 17 Jan 2001 03:16:03 -0500 (EST)
Received: (qmail 26865 invoked by uid 510); 17 Jan 2001 08:54:01 -0000
Message-ID: <20010117085401.26864.qmail@mailweb5.rediffmail.com>
Received: from unknown (203.195.142.45) by rediffmail.com via HTTP; 17 Jan 2001 08:54:01 -0000
MIME-Version: 1.0
To: "Sip@lists.bell-labs.com" <Sip@lists.bell-labs.com>
From: "Divya  Nath" <divyanath@rediffmail.com>
Content-ID: <Wed_Jan_17_14_24_01_IST_2001_0@mailweb5.rediffmail.com>
Content-type: text/plain
Content-Transfer-Encoding: 7bit
Subject: [SIP] Tag in From Field
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 17 Jan 2001 08:54:01 -0000
Content-Transfer-Encoding: 7bit

   As specified in section 6.26 of draft-ietf-sip-rfc2543bis-0.2 
" A tag in From field must be present when it is possible that the two instances of a user sharing a SIP address can make call invitations with the same Call-Id."
What I am unable to understand is when can the Call-Id be same since as per my understanding the Call-Id is globally unique within a single boot cycle .
Can anybody please clearify the same .
Thanx & Regards
Divya


_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 06:09:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15418
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 06:09:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7B92044346; Wed, 17 Jan 2001 05:10:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web10304.mail.yahoo.com (web10304.mail.yahoo.com [216.136.130.82])
	by lists.bell-labs.com (Postfix) with SMTP id 881C144336
	for <SIP@lists.bell-labs.com>; Wed, 17 Jan 2001 05:09:39 -0500 (EST)
Message-ID: <20010117110926.6267.qmail@web10304.mail.yahoo.com>
Received: from [203.200.4.212] by web10304.mail.yahoo.com; Wed, 17 Jan 2001 03:09:26 PST
From: james jack <sipjames@yahoo.com>
To: SIP@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] Some idea on Stateful SIP Proxy for Card Service
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 03:09:26 -0800 (PST)

Dear All:
   My question is on card serice, how to realize
 the traditional card service with SIP. one difficulty
 is that if the money in the card is over, how to
 control the terminal to break the connection.
   For example, User B use the Terminal to dial
 terminal C through Proxy P, the charging is
controlled by the application layer in proxy P--which
can contact the database, then if the money in the
card is over, how to control to break the connection?
   In my opinion, the application layer of Proxy P
 can send a instruction, then the proxy send BYE to
both sides (B and C), then the connection can be
broken.
  But the proxy will never generate BYE request
according to RFC2543?  then how to solve such problem?
  Any suggestions and ideas are welcome!
  I am looking forwards to getting your reply as
 soon as possible!
     Best Regards!
                           Yours: james


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 06:23:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15464
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 06:23:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 416A044395; Wed, 17 Jan 2001 05:24:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from hindon.hss.co.in (unknown [202.54.26.202])
	by lists.bell-labs.com (Postfix) with ESMTP id 0C6C444391
	for <SIP@lists.bell-labs.com>; Wed, 17 Jan 2001 05:23:22 -0500 (EST)
Received: from hsssun01.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f0HBNq205559;
	Wed, 17 Jan 2001 16:54:16 +0530 (IST)
Received: from sampark.hss.hns.com (sampark [139.85.229.22])
	by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id f0HBVgk18697;
	Wed, 17 Jan 2001 17:01:47 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 652569D7.003E9CB1 ; Wed, 17 Jan 2001 16:53:53 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: james jack <sipjames@yahoo.com>
Cc: SIP@lists.bell-labs.com
Message-ID: <652569D7.003E9BC6.00@sampark.hss.hns.com>
Subject: Re: [SIP] Some idea on Stateful SIP Proxy for Card Service
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 16:53:50 +0530



If you want such services, your SIP entity might serve as a B2BUA for this
interaction.
Note that Stateless/full Proxy, Redirect, modes are logic roles - your SIP
entity can change its
behaviour depending on their needs.
In this case, if you want your server to send a BYE to both parties, it
will be taking the role of a B2BUA
 and not that of a regular SIP Proxy functionality. See the 3pcc drafts for
examples of B2BUAs.

The important point to realise is that when you a deploying services such
as above, you will often use a combination
of these logical roles - that of a Proxy, Redirect, B2BUA etc. The
"physical" entity that you install, will change its "logical"
role depending on what it needs to do to provide a service.


Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems







james jack <sipjames@yahoo.com> on 01/17/2001 04:39:26 PM

To:   SIP@lists.bell-labs.com
cc:

Subject:  [SIP] Some idea on Stateful SIP Proxy for Card Service




Dear All:
   My question is on card serice, how to realize
 the traditional card service with SIP. one difficulty
 is that if the money in the card is over, how to
 control the terminal to break the connection.
   For example, User B use the Terminal to dial
 terminal C through Proxy P, the charging is
controlled by the application layer in proxy P--which
can contact the database, then if the money in the
card is over, how to control to break the connection?
   In my opinion, the application layer of Proxy P
 can send a instruction, then the proxy send BYE to
both sides (B and C), then the connection can be
broken.
  But the proxy will never generate BYE request
according to RFC2543?  then how to solve such problem?
  Any suggestions and ideas are welcome!
  I am looking forwards to getting your reply as
 soon as possible!
     Best Regards!
                           Yours: james


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.





_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 06:34:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15540
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 06:34:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 06A174439E; Wed, 17 Jan 2001 05:35:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from aurora.tsm.es (unknown [194.224.100.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 37F9244391
	for <SIP@lists.bell-labs.com>; Wed, 17 Jan 2001 05:34:22 -0500 (EST)
Received: by aurora.tsm.es; (8.8.8/1.3/10May95) id MAA31226; Wed, 17 Jan 2001 12:34:21 +0100 (MET)
From: <ferreiro_j@tsm.es>
Subject: Re: [SIP] Some idea on Stateful SIP Proxy for Card Service
To: james jack <sipjames@yahoo.com>
Cc: SIP@lists.bell-labs.com
Message-ID: <OFF9C700BD.2209B432-ONC12569D7.003E9118@tsm.es>
X-MIMETrack: Serialize by Router on abantos/TSM(
 =?iso-8859-1?q?Versi=F3n_5=2E0=2E5_|Octubre_21=2C_2000=29_at_17=2F01=2F?=
 =?us-ascii?q?2001?= 12:31:51 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 12:31:49 +0100



You can check Third Party Call Control in SIP
(draft-rosenberg-sip-3pcc-01.txt) and, since it seems that you want to base
the charging on SIP message flows,  SIP session timer
(draft-ietf-sip-session-timer-04.txt)) in order to avoid neverending
charging when there is any problem when delivering BYE message.

Javier



>Dear All:
>   My question is on card serice, how to realize
> the traditional card service with SIP. one difficulty
> is that if the money in the card is over, how to
> control the terminal to break the connection.
>   For example, User B use the Terminal to dial
> terminal C through Proxy P, the charging is
>controlled by the application layer in proxy P--which
>can contact the database, then if the money in the
>card is over, how to control to break the connection?
>   In my opinion, the application layer of Proxy P
> can send a instruction, then the proxy send BYE to
>both sides (B and C), then the connection can be
>broken.
>  But the proxy will never generate BYE request
>according to RFC2543?  then how to solve such problem?
>  Any suggestions and ideas are welcome!
>  I am looking forwards to getting your reply as
> soon as possible!
>     Best Regards!
>                           Yours: james


__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.




_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 06:56:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15650
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 06:56:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6FD5844346; Wed, 17 Jan 2001 05:57:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by lists.bell-labs.com (Postfix) with ESMTP id 2B77144336
	for <SIP@lists.bell-labs.com>; Wed, 17 Jan 2001 05:56:04 -0500 (EST)
Received: from fokus.gmd.de (dhcp012 [195.37.78.140])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id MAA07256;
	Wed, 17 Jan 2001 12:55:49 +0100 (MET)
Message-ID: <3A65883A.11BC215B@fokus.gmd.de>
From: Jiri Kuthan <kuthan@fokus.gmd.de>
Organization: GMD Fokus
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: james jack <sipjames@yahoo.com>
Cc: SIP@lists.bell-labs.com
Subject: Re: [SIP] Some idea on Stateful SIP Proxy for Card Service
References: <20010117110926.6267.qmail@web10304.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 12:55:38 +0100
Content-Transfer-Encoding: 7bit

I believe the question can be answered if details of the scenario
are known. 

For example, in the most simple PC-to-PC scenario w/o QoS you will send
your signaling request to callee's proxy. It seems unlikely to me that 
the proxy will charge any of call parties for call duration. I can rather
think of a web-like charging model in which the called party will be
charged flat-rate fees or compelled to receive advertising JPEGs attached
by the proxy to incoming invitations. If your SIP proxy provider insists
on per-minute charges, I'd recommend you subscribing to some other one.
Obviously, if there are no per-minute charges prepaid cards do not
make so much sense.

If you look at a PC-to-phone scenario, a gateway may want to project
PSTN per-minute charges into your bill. In such a case, implementing prepaid 
card services could be useful but is not very difficult. A gateway acts from 
SIP perspective as a UA and can easily terminate a call by sending BYE as any 
other UA would. No third-party call termination is needed. 

Jiri

james jack wrote:
> 
> Dear All:
>    My question is on card serice, how to realize
>  the traditional card service with SIP. one difficulty
>  is that if the money in the card is over, how to
>  control the terminal to break the connection.
>    For example, User B use the Terminal to dial
>  terminal C through Proxy P, the charging is
> controlled by the application layer in proxy P--which
> can contact the database, then if the money in the
> card is over, how to control to break the connection?
>    In my opinion, the application layer of Proxy P
>  can send a instruction, then the proxy send BYE to
> both sides (B and C), then the connection can be
> broken.
>   But the proxy will never generate BYE request
> according to RFC2543?  then how to solve such problem?
>   Any suggestions and ideas are welcome!
>   I am looking forwards to getting your reply as
>  soon as possible!
>      Best Regards!
>                            Yours: james
> 
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.

-- 
Jiri Kuthan         http://www.fokus.gmd.de/usr/kuthan
		    tel:+49-30-34637271
Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 07:46:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16130
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 07:46:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 50BDD44346; Wed, 17 Jan 2001 06:47:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
	by lists.bell-labs.com (Postfix) with ESMTP id 731A944336
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 06:46:06 -0500 (EST)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-blue.research.att.com (Postfix) with ESMTP id 01B584CE67
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 07:45:53 -0500 (EST)
Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id HAA06184
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 07:45:53 -0500 (EST)
From: William Marshall <wtm@research.att.com>
Received: (from wtm@localhost)
	by fish-ha.research.att.com (SGI-8.9.3/8.8.5) id HAA28700
	for sip@lists.bell-labs.com; Wed, 17 Jan 2001 07:46:31 -0500 (EST)
Message-Id: <200101171246.HAA28700@fish-ha.research.att.com>
Subject: Re: [SIP] Some idea on Stateful SIP Proxy for Card Service
To: sip@lists.bell-labs.com
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 07:46:31 -0500 (EST)

P is clearly a back-to-back-UA, since it speaks SIP to
both user B and terminal C.  However, its need to initiate
a BYE doesn't fit the profile of a proxy.  Just a B2BUA.

In looking at various enhanced services, it is not clear
to me that a "stateful proxy" will ever exist.  They will
all be B2BUAs for some case or another.

Bill Marshall
wtm@research.att.com


james jack wrote:
> 
> Dear All:
>    My question is on card serice, how to realize
>  the traditional card service with SIP. one difficulty
>  is that if the money in the card is over, how to
>  control the terminal to break the connection.
>    For example, User B use the Terminal to dial
>  terminal C through Proxy P, the charging is
> controlled by the application layer in proxy P--which
> can contact the database, then if the money in the
> card is over, how to control to break the connection?
>    In my opinion, the application layer of Proxy P
>  can send a instruction, then the proxy send BYE to
> both sides (B and C), then the connection can be
> broken.
>   But the proxy will never generate BYE request
> according to RFC2543?  then how to solve such problem?
>   Any suggestions and ideas are welcome!
>   I am looking forwards to getting your reply as
>  soon as possible!
>      Best Regards!
>                            Yours: james
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 09:51:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19238
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 09:51:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E75E54433C; Wed, 17 Jan 2001 08:52:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by lists.bell-labs.com (Postfix) with ESMTP id A105444336
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 08:51:53 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f0HEpbC17659;
	Wed, 17 Jan 2001 15:51:37 +0100 (MET)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.38])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA28667;
	Wed, 17 Jan 2001 16:51:36 +0200 (EET)
Message-ID: <3A65B163.166C261B@lmf.ericsson.se>
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Cc: Michael Thomas <mat@cisco.com>
Subject: Re: [SIP] Media after INVITE
References: <3A63F0E3.459BA9E7@lmf.ericsson.se> <14948.32787.751400.408672@thomasm-u1.cisco.com>
Content-Type: multipart/mixed;
 boundary="------------D2CC586C34992921F9E98D9C"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 16:51:15 +0200

This is a multi-part message in MIME format.
--------------D2CC586C34992921F9E98D9C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

>>Hi,
>>
>>I was reading the thread about Early media replacement. My question,
>>however, has not so much to do with the 183-to-be-or-not-to-be, but
>>rather with the requirement that a UA should be able to receive media
>>after the first INVITE is sent. This mean that the remote user wouldn't
>>have to send any response at all - instead he could start sending media
>>and would never be charged for it. Yes, the re-transmission timer for
>>the INVITE will expire, and the call will be dropped, but until that the
>>remote party have plenty of time to send media to the caller (even if
>>it's only one-way, it can be a news service/weather service/ voice mail/
>>whatever, where two-way direction is not needed).
> 
>I believe that this is an appeal to put the best
>effort genie back in the bottle. Namely, unless
>there is some way to prevent two cooperating
>parties from sending traffic to one another
>(firewall, elevated qos), early media is the least
>of your worries. I could just as easily send you a
>mail message with an SDP announcement and
>circumvent your biller, after all.

Well, I assumed that you are somehow dependent of your service
provider/operator. Otherwise you and your friend can get a couple of SIP
phones and talk to each other directly for free...

Also, sending the SDP in a mail doesn't help very much if you are making
a PSTN-to-SIP call.
 
Regards,

Christer (lmfchh)
--------------D2CC586C34992921F9E98D9C
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------D2CC586C34992921F9E98D9C--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 09:56:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19327
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 09:56:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A336944399; Wed, 17 Jan 2001 08:57:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id 6339E44336
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 08:56:25 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f0HEu2d18765;
	Wed, 17 Jan 2001 15:56:04 +0100 (MET)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.38])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id QAA28793;
	Wed, 17 Jan 2001 16:56:00 +0200 (EET)
Message-ID: <3A65B26A.5052DC04@lmf.ericsson.se>
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Cc: Rick Dean <siplist@fdd.com>
Subject: Re: [SIP] Media after INVITE
References: <3A63F0E3.459BA9E7@lmf.ericsson.se> <20010116111257.A5777@fdd.com>
Content-Type: multipart/mixed;
 boundary="------------D2EDAE3E53D6B65C722041DE"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 16:55:38 +0200

This is a multi-part message in MIME format.
--------------D2EDAE3E53D6B65C722041DE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

>>Hi,
>>
>>I was reading the thread about Early media replacement. My question,
>>however, has not so much to do with the 183-to-be-or-not-to-be, but
>>rather with the requirement that a UA should be able to receive media
>>after the first INVITE is sent. This mean that the remote user wouldn't
>>have to send any response at all - instead he could start sending media
>>and would never be charged for it. Yes, the re-transmission timer for
>>the INVITE will expire, and the call will be dropped, but until that the
>>remote party have plenty of time to send media to the caller (even if
>>it's only one-way, it can be a news service/weather service/ voice mail/
>>whatever, where two-way direction is not needed).
>200 OK need not be tied to billing.  In typical phone systems each
>device creates a call detail record (CDR) which contains more
>information and is used for billing.  For this example the gateway
>CDR would probably be relied upon.

Yes, but the gateway must also know when to start the billing.
 
>Some systems like AT&T cell phones charge for ringback.  Maybe
>SIP gateway service will write their contracts similarly.  The
>ringback need not be sent as RTP.

No, the gateway can also e.g. generate a local ringback tone, or play
some message, but then the gateway will control this and can charge if
needed.

Regards,

Christer Holmberg
Ericsson Finland
--------------D2EDAE3E53D6B65C722041DE
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------D2EDAE3E53D6B65C722041DE--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 10:55:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20676
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 10:55:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 84E3E4438C; Wed, 17 Jan 2001 09:56:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.bell-labs.com (Postfix) with ESMTP id 4BDE34439B
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 07:11:34 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16586;
	Wed, 17 Jan 2001 08:11:20 -0500 (EST)
Message-Id: <200101171311.IAA16586@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@lists.bell-labs.com
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: [SIP] I-D ACTION:draft-ietf-sip-srv-01.txt
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 08:11:20 -0500

--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		: SIP: Session Initiation Protocol -- Locating SIP 
                          Servers
	Author(s)	: H. Schulzrinne, J. Rosenberg
	Filename	: draft-ietf-sip-srv-01.txt
	Pages		: 6
	Date		: 16-Jan-01
	
This document describes how a SIP client locates a SIP server based
on the Request-URI or a preconfigured outbound proxy server. This
document updates the process described in RFC 2543.

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

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-srv-01.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-srv-01.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:	<20010116125731.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-srv-01.txt

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

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

--OtherAccess--

--NextPart--



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 10:57:25 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20714
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 10:57:24 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 49127443A8; Wed, 17 Jan 2001 09:56:13 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.bell-labs.com (Postfix) with ESMTP id 69FE94439B
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 07:11:38 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16565;
	Wed, 17 Jan 2001 08:11:14 -0500 (EST)
Message-Id: <200101171311.IAA16565@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@lists.bell-labs.com
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: [SIP] I-D ACTION:draft-ietf-sip-dhcp-02.txt
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 08:11:14 -0500

--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		: DHCP Option for SIP Servers
	Author(s)	: G. Nair, H. Schulzrinne
	Filename	: draft-ietf-sip-dhcp-02.txt
	Pages		: 4
	Date		: 16-Jan-01
	
This document defines a DHCP option that contains a pointers to one
or more SIP servers. This is one of the many methods that a SIP
client can use to obtain the addresses of a local oubound SIP server.

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

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-dhcp-02.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-dhcp-02.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:	<20010116125723.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-dhcp-02.txt

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

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

--OtherAccess--

--NextPart--



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 12:17:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22302
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 12:17:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2D3864433C; Wed, 17 Jan 2001 11:18:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 3805644336
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 11:17:15 -0500 (EST)
Received: from whoami.cisco.com (whoami.cisco.com [171.71.157.47])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA01537
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 09:17:11 -0800 (PST)
Received: from rtbell-isdn4.cisco.com (rtbell-isdn5.cisco.com [10.21.5.70])
	by whoami.cisco.com (Mirapoint)
	with ESMTP id AAE31593 (AUTH rtbell);
	Wed, 17 Jan 2001 04:20:50 -0600 (CST)
Message-Id: <5.0.2.1.2.20010117094702.00a70300@whoami.cisco.com>
X-Sender: rtbell@whoami.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
To: sip@lists.bell-labs.com
From: Bob Bell <rtbell@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] Authorization Header and content question
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 10:16:52 -0700

In studying section 14.1.2 of rfc2543bis-02, I have raised three questions 
relative to the use of digitally signed messages. The first is the message 
content that is to be signed.

In the second paragraph of the pgp-signature description, the order of 
processing is specified as "... the nonce (if present), realm, request 
method, request version, and header fields following the Authorization 
header and the message body, in the same order as they appear in the 
message. ... The signature is computed across the headers as sent, and the 
terminating CRLF. The CRLF following the Authorization header is NOT 
included in the signature."  There is Authorization header information 
which is extracted from within the header (notably the nonce and realm 
fields). Are those fields again processed while computing over the 
Authorization header?

The second question is related to the first in that it is obvious that the 
signature itself is not included in the signature. Is there any reason to 
include the Authorization header per se into the signature since the nonce 
and realm are already included? This would then totally exclude the 
Authorization header from the signature computation itself and perhaps make 
the description more understandable.

Third, in the informational draft entitled 
"draft-ietf-sip-call-flows-02.txt", section 2.1.x, there are several 
examples of messages containing Authorization headers. Each Authorization 
header is the last header in the message. Yet in rfc2543bis-02, in section 
14.1.2, the calculation of the signature is said to include all headers 
following the Authorization header and that "Receivers of signed SIP 
messages SHOULD discard any end-to-end header fields above the 
Authorization header, as they may have been maliciously added en route by a 
proxy." This would lead one to believe that all information contained in 
the REGISTER messages SHOULD be discarded. In studying the procedures 
outlined, I presume that the proper placement for the Authorization header 
is immediately following the Via header. Since the Via header is properly 
modified en route, its contents cannot be protected with a signature from 
the originating endpoint. All other end-to-end fields should however follow 
the Authorization header so as to be included in the signature and thus 
protected. Is my assumption correct?

One final question unrelated to the preceding ones. The rfc2543bis-02 
provides for methods of signing and thus authenticating requests from the 
user to the proxy. However, there is no inherent method of authenticating 
the proxy messaging. If the overhead of the IPSec security association is 
incurred, then, through means outside the protocol, such mutual 
authentication is possible. However, if the use of signatures is extended 
to include messages from the proxy, such mutual authentication could be had 
within the confines of the protocol itself without invoking other outside 
means. I believe this could be a valuable addition to the protocol.

Thanks for your help and consideration ---- Bob Bell

Bob Bell
Cisco Systems Inc.
801-294-3034(v)
801-294-3023(f)


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 12:43:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22774
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 12:43:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A28B14433C; Wed, 17 Jan 2001 11:44:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from guardian1.tlv.radvision.com (unknown [212.143.185.30])
	by lists.bell-labs.com (Postfix) with ESMTP id 8A4634433B
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 11:43:02 -0500 (EST)
Received: from nt-mail.tlv.radvision.com ([172.20.2.100])
          by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3
          release 223 ID# 0-0U10L2S100V35) with ESMTP id com;
          Wed, 17 Jan 2001 20:40:19 +0200
Received: by NT-MAIL with Internet Mail Service (5.5.2650.21)
	id <DC0D47C5>; Wed, 17 Jan 2001 19:44:40 +0200
Message-ID: <E09383987EE5D3119F2E0008C7097728014D756E@NT-MAIL>
From: Itamar Gilad <ItamarG@tlv.radvision.com>
To: "'Bob Bell'" <rtbell@cisco.com>
Cc: "'SIP List'" <sip@lists.bell-labs.com>
Subject: RE: [SIP] Authorization Header and content question
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 19:44:39 +0200



> -----Original Message-----
> From: Bob Bell [mailto:rtbell@cisco.com]
> Sent: Wed, January 17, 2001 7:17 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Authorization Header and content question
> 

...
> 
> Third, in the informational draft entitled 
> "draft-ietf-sip-call-flows-02.txt", section 2.1.x, there are several 
> examples of messages containing Authorization headers. Each 
> Authorization 
> header is the last header in the message. Yet in 
> rfc2543bis-02, in section 
> 14.1.2, the calculation of the signature is said to include 
> all headers 
> following the Authorization header and that "Receivers of signed SIP 
> messages SHOULD discard any end-to-end header fields above the 
> Authorization header, as they may have been maliciously added 
> en route by a 
> proxy." This would lead one to believe that all information 
> contained in 
> the REGISTER messages SHOULD be discarded. In studying the procedures 
> outlined, I presume that the proper placement for the 
> Authorization header 
> is immediately following the Via header. Since the Via header 
> is properly 
> modified en route, its contents cannot be protected with a 
> signature from 
> the originating endpoint. All other end-to-end fields should 
> however follow 
> the Authorization header so as to be included in the 
> signature and thus 
> protected. Is my assumption correct?

I think you're confusing Digest authentication with more elaborate schemes.
The rules you refer to don't apply to digest auth and most of the traces in
the call flows draft actually use digest auth.

  Itamar

> Thanks for your help and consideration ---- Bob Bell
> 
> Bob Bell
> Cisco Systems Inc.
> 801-294-3034(v)
> 801-294-3023(f)
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 12:53:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22944
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 12:53:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3595E4433C; Wed, 17 Jan 2001 11:54:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 14F3E44336
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 11:53:17 -0500 (EST)
Received: from whoami.cisco.com (whoami.cisco.com [171.71.157.47])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA05600;
	Wed, 17 Jan 2001 09:53:17 -0800 (PST)
Received: from rtbell-isdn4.cisco.com (rtbell-isdn5.cisco.com [10.21.5.70])
	by whoami.cisco.com (Mirapoint)
	with ESMTP id AAE31657 (AUTH rtbell);
	Wed, 17 Jan 2001 04:56:58 -0600 (CST)
Message-Id: <5.0.2.1.2.20010117105027.03078750@whoami.cisco.com>
X-Sender: rtbell@whoami.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
To: Itamar Gilad <ItamarG@tlv.radvision.com>
From: Bob Bell <rtbell@cisco.com>
Subject: RE: [SIP] Authorization Header and content question
Cc: "'SIP List'" <sip@lists.bell-labs.com>
In-Reply-To: <E09383987EE5D3119F2E0008C7097728014D756E@NT-MAIL>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 10:53:00 -0700

Itamar -

I appreciate your quick response. I saw that the call flows used the digest 
method and I was trying to generalize the approach to include the PGP 
method so your observation relative to the digest method is well taken. 
However, in the case of the PGP method, shouldn't the Authorization header 
follow the Via header for the reasons I outlined?

Bob

At 10:44  1/17/2001, Itamar Gilad wrote:


> > -----Original Message-----
> > From: Bob Bell [mailto:rtbell@cisco.com]
> > Sent: Wed, January 17, 2001 7:17 PM
> > To: sip@lists.bell-labs.com
> > Subject: [SIP] Authorization Header and content question
> >
>
>...
> >
> > Third, in the informational draft entitled
> > "draft-ietf-sip-call-flows-02.txt", section 2.1.x, there are several
> > examples of messages containing Authorization headers. Each
> > Authorization
> > header is the last header in the message. Yet in
> > rfc2543bis-02, in section
> > 14.1.2, the calculation of the signature is said to include
> > all headers
> > following the Authorization header and that "Receivers of signed SIP
> > messages SHOULD discard any end-to-end header fields above the
> > Authorization header, as they may have been maliciously added
> > en route by a
> > proxy." This would lead one to believe that all information
> > contained in
> > the REGISTER messages SHOULD be discarded. In studying the procedures
> > outlined, I presume that the proper placement for the
> > Authorization header
> > is immediately following the Via header. Since the Via header
> > is properly
> > modified en route, its contents cannot be protected with a
> > signature from
> > the originating endpoint. All other end-to-end fields should
> > however follow
> > the Authorization header so as to be included in the
> > signature and thus
> > protected. Is my assumption correct?
>
>I think you're confusing Digest authentication with more elaborate schemes.
>The rules you refer to don't apply to digest auth and most of the traces in
>the call flows draft actually use digest auth.
>
>   Itamar
>
> > Thanks for your help and consideration ---- Bob Bell
> >
> > Bob Bell
> > Cisco Systems Inc.
> > 801-294-3034(v)
> > 801-294-3023(f)
> >
> >
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> >

Bob Bell
Cisco Systems Inc.
801-294-3034(v)
801-294-3023(f)


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 13:26:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23590
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 13:26:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1851644349; Wed, 17 Jan 2001 12:27:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 6250D4433C
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 12:26:48 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0HIQdH30112
	for sip@lists.bell-labs.com; Wed, 17 Jan 2001 12:26:39 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: sip@lists.bell-labs.com
Message-ID: <20010117122634.A5496@fdd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [SIP] draft-ietf-sip-handoff-00pre8.txt
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 12:26:34 -0600


Dear SIP list,

Although we would like more time to 
edit this poor draft, we feel a sneak
peek is warranted due to its urgent nature
with the upcomming meeting.

http://phonectl.sfour.com/draft-ietf-sip-handoff-00pre8.txt

Some significant differences from REFER are:
  * narrower scope
  * method completes without prompting
  * referred-by like header generated by transferee
  * location of headers for spawned invite
  * error processing & final notification

Cheers,
Rick
rick_dean@3com.com


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 16:17:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26265
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 16:17:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9882A4433B; Wed, 17 Jan 2001 15:18:04 -0500 (EST)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id CACFA44336
	for <sip@share.research.bell-labs.com>; Wed, 17 Jan 2001 15:17:34 -0500 (EST)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Jan 17 16:14:36 EST 2001
Received: by lists.bell-labs.com (Postfix)
	id B727444380; Wed, 17 Jan 2001 16:02:47 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5])
	by lists.bell-labs.com (Postfix) with SMTP id 7441A4437D
	for <Sip@lists.bell-labs.com>; Wed, 17 Jan 2001 16:02:47 -0500 (EST)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id PAA18439; Wed, 17 Jan 2001 15:02:42 -0600
Cc: "Sip@lists.bell-labs.com" <Sip@lists.bell-labs.com>
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id PAA18385; Wed, 17 Jan 2001 15:02:41 -0600
Message-ID: <3A660869.DAE0CAED@lucent.com>
From: Vijay Gurbani <vkg@lucent.com>
Organization: Lucent Technologies/Bell Laboratories
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Divya Nath <divyanath@rediffmail.com>
Original-CC: "Sip@lists.bell-labs.com" <Sip@lists.bell-labs.com>
Subject: Re: [SIP] Tag in From Field
References: <20010117085401.26864.qmail@mailweb5.rediffmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 15:02:33 -0600
Content-Transfer-Encoding: 7bit

Divya Nath wrote:
> 
>    As specified in section 6.26 of draft-ietf-sip-rfc2543bis-0.2
> " A tag in From field must be present when it is possible that the two 
>instances of a user sharing a SIP address can make call invitations with 
> the same Call-Id."
> What I am unable to understand is when can the Call-Id be same since as per my understanding the Call-Id is globally unique within a single boot 
> cycle .
> Can anybody please clearify the same .

Divya:

One way for a single Call-ID to have two instances of a user sharing a SIP
address is when a proxy forks an INVITE request.  Each of the forked 
requests will have the same From (including tags) as that of the original.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 17:07:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26860
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 17:07:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8F6F04433B; Wed, 17 Jan 2001 16:08:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail15b.boca15-verio.com (unknown [208.55.91.59])
	by lists.bell-labs.com (Postfix) with SMTP id 86A9B44336
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 16:07:23 -0500 (EST)
Received: from 128.241.144.247 (128.241.144.247)
	by mail15b.boca15-verio.com (RS ver 1.0.58s) with SMTP id 1317709767
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 17:06:49 -0500 (EST)
From: "Eric Burger" <eburger@snowshore.com>
To: <sip@lists.bell-labs.com>
Subject: RE: [SIP] Early media replacement.
Message-ID: <NEBBLACLCLHMJBCAJGOECEMKCIAA.eburger@snowshore.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <20010116105905.A22043@fdd.com>
X-Loop-Detect: 1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 17:07:17 -0500
Content-Transfer-Encoding: 7bit

Why no middle ground:

200 OK :  The call is established, everyone's happy
183 :     Something's going on that I understand; here it is...
184 :     Something's going on that I don't understand; here's the audio

This gets around just about all of the issues raised:

1. Either a call is established (200) or it's in the process of being
established (18x).  Established calls have the audio path established.
Calls not established (181, 182, 183, et. al.) don't have the audio path
established, except for the case of 184.

2. If there's a billing policy that needs to police media cut-through, it
can trigger off the 184 message.

3. It's forward compatible: as we get a truly digital GSTN, the dependence
on audio cut-through for human call progress analysis will go away.  By not
overloading 183, we make life much easier.

> ----- Forwarded message from Rick Dean <siplist@fdd.com> -----
> Date: Tue, 16 Jan 2001 10:58:05 -0600
> From: Rick Dean <siplist@fdd.com>
> In-Reply-To:
> <B65B4F8437968F488A01A940B21982BF9AB0D8@DYN-EXCH-001.dynamicsoft.c
> om>; from jdrosen@dynamicsoft.com on Tue, Jan 16, 2001 at 01:34:26AM -0500
>
> On Tue, Jan 16, 2001 at 01:34:26AM -0500, Jonathan Rosenberg wrote:
> > > -----Original Message-----
> > > From: Rick Dean [mailto:siplist@fdd.com]
> > >
> > > On Tue, Jan 09, 2001 at 01:25:41AM -0500, Jonathan Rosenberg wrote:
[snip]
> > > PSTN interoperability is paramount to me.
> > > Unfortunately, my calls need to work better
> > > than 99% of the time.
[snip]
> Sure, if a gateway knows the far end is busy, it should send
> a 486 busy -- no debate.  If the gateway has unknown progress media
> which might be busy-tone, ringback, or voice prompting; sending 200
> OK helps manage the audio channel.   Do you expect the human to
> hit a key on busy tone so his UA sends a CANCEL?  or should
> he just know to wait?
>
> I regret the 200 OK notion.  With audio, I argue a session
> is established.  As a call originating UA, how to I suspend or
> redirect the early media if my INVITE won't complete?
>
> Sorry to be such as pain on this subject.
[snip]
> > >  Hopefully, the gateway builders will
> > > do the right thing.
> >
> > Its not a question of lazy implementations. Its a question of not having
> > enough
> > information to send anything but early media.


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 17:38:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27431
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 17:38:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C0CA54433B; Wed, 17 Jan 2001 16:39:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 62D9F44336
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 16:38:41 -0500 (EST)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <CKD5P9YF>; Wed, 17 Jan 2001 14:38:26 -0800
Message-ID: <E79883AEA37FD411A58C00508BAC5F4B2B5C7D@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Eric Burger'" <eburger@snowshore.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Early media replacement.
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C080D6.346D9F50"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 14:38:25 -0800

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_01C080D6.346D9F50
Content-Type: text/plain;
	charset="iso-8859-1"

Eric,

If a gateway, knows what's going on then it should send the appropriate
response code (ie, 180, 182, etc with SDP). If the gateway _doesn't_ know
what is going on then it can only send the 183 Session Progress response.
It's not really helpful if the gateway knows what is happening but sends a
response that doesn't convey any information (ie, 183 with SDP)! We don't
need another "I don't know what's going on" Response Code. ("184 Session
Confused"??<grin>)

Robert.

-- My opinions are my own and should not be taken as representing those of
Nuera Communications, Inc. -- 


		-----Original Message-----
		From:	Eric Burger [mailto:eburger@snowshore.com]
		Sent:	Thursday, January 18, 2001 9:07 AM
		To:	sip@lists.bell-labs.com
		Subject:	RE: [SIP] Early media replacement.

		Why no middle ground:

		200 OK :  The call is established, everyone's happy
		183 :     Something's going on that I understand; here it
is...
		184 :     Something's going on that I don't understand;
here's the audio

		This gets around just about all of the issues raised:

		1. Either a call is established (200) or it's in the process
of being
		established (18x).  Established calls have the audio path
established.
		Calls not established (181, 182, 183, et. al.) don't have
the audio path
		established, except for the case of 184.

		2. If there's a billing policy that needs to police media
cut-through, it
		can trigger off the 184 message.

		3. It's forward compatible: as we get a truly digital GSTN,
the dependence
		on audio cut-through for human call progress analysis will
go away.  By not
		overloading 183, we make life much easier.

		> ----- Forwarded message from Rick Dean <siplist@fdd.com>
-----
		> Date: Tue, 16 Jan 2001 10:58:05 -0600
		> From: Rick Dean <siplist@fdd.com>
		> In-Reply-To:
		>
<B65B4F8437968F488A01A940B21982BF9AB0D8@DYN-EXCH-001.dynamicsoft.c
		> om>; from jdrosen@dynamicsoft.com on Tue, Jan 16, 2001 at
01:34:26AM -0500
		>
		> On Tue, Jan 16, 2001 at 01:34:26AM -0500, Jonathan
Rosenberg wrote:
		> > > -----Original Message-----
		> > > From: Rick Dean [mailto:siplist@fdd.com]
		> > >
		> > > On Tue, Jan 09, 2001 at 01:25:41AM -0500, Jonathan
Rosenberg wrote:
		[snip]
		> > > PSTN interoperability is paramount to me.
		> > > Unfortunately, my calls need to work better
		> > > than 99% of the time.
		[snip]
		> Sure, if a gateway knows the far end is busy, it should
send
		> a 486 busy -- no debate.  If the gateway has unknown
progress media
		> which might be busy-tone, ringback, or voice prompting;
sending 200
		> OK helps manage the audio channel.   Do you expect the
human to
		> hit a key on busy tone so his UA sends a CANCEL?  or
should
		> he just know to wait?
		>
		> I regret the 200 OK notion.  With audio, I argue a session
		> is established.  As a call originating UA, how to I
suspend or
		> redirect the early media if my INVITE won't complete?
		>
		> Sorry to be such as pain on this subject.
		[snip]
		> > >  Hopefully, the gateway builders will
		> > > do the right thing.
		> >
		> > Its not a question of lazy implementations. Its a
question of not having
		> > enough
		> > information to send anything but early media.


		_______________________________________________
		This list is for continuing development of the SIP protocol.
		The sip-implementer's list is the place to discuss
implementation,
		and to receive advice on understanding existing sip.
		To subscribe to it, send mail to majordomo@cs.columbia.edu
with
		"subscribe sip-implementors" in the body.

------_=_NextPart_001_01C080D6.346D9F50
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [SIP] Early media replacement.</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Eric,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If a gateway, knows what's going on =
then it should send the appropriate response code (ie, 180, 182, etc =
with SDP). If the gateway _</FONT><I><FONT SIZE=3D2 =
FACE=3D"Arial">doesn't</FONT></I><FONT SIZE=3D2 FACE=3D"Arial">_ know =
what is going on then it can only send the 183 Session Progress =
response. It's not really helpful if the gateway knows what is =
happening but sends a response that doesn't convey any information (ie, =
183 with SDP)! We don't need another "I don't know what's going on" =
Response Code. ("184 Session Confused"??&lt;grin&gt;)</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Robert.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- My opinions are my own and should =
not be taken as representing those of Nuera Communications, Inc. -- =
</FONT>
</P>
<BR>
<UL><UL>
<P><A NAME=3D"_MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original =
Message-----</FONT></A>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:&nbsp;&nbsp; Eric Burger [<A =
HREF=3D"mailto:eburger@snowshore.com">mailto:eburger@snowshore.com</A>]<=
/FONT></B>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D2 FACE=3D"Arial">Thursday, January 18, 2001 9:07 AM</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">sip@lists.bell-labs.com</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D2 FACE=3D"Arial">RE: [SIP] Early media =
replacement.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Why no middle ground:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">200 OK :&nbsp; The call is =
established, everyone's happy</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">183 :&nbsp;&nbsp;&nbsp;&nbsp; =
Something's going on that I understand; here it is...</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">184 :&nbsp;&nbsp;&nbsp;&nbsp; =
Something's going on that I don't understand; here's the audio</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This gets around just about all of the =
issues raised:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">1. Either a call is established (200) =
or it's in the process of being</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">established (18x).&nbsp; Established =
calls have the audio path established.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Calls not established (181, 182, 183, =
et. al.) don't have the audio path</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">established, except for the case of =
184.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">2. If there's a billing policy that =
needs to police media cut-through, it</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">can trigger off the 184 =
message.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">3. It's forward compatible: as we get =
a truly digital GSTN, the dependence</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">on audio cut-through for human call =
progress analysis will go away.&nbsp; By not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">overloading 183, we make life much =
easier.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; ----- Forwarded message from Rick =
Dean &lt;siplist@fdd.com&gt; -----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Date: Tue, 16 Jan 2001 10:58:05 =
-0600</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; From: Rick Dean =
&lt;siplist@fdd.com&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; In-Reply-To:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; =
&lt;B65B4F8437968F488A01A940B21982BF9AB0D8@DYN-EXCH-001.dynamicsoft.c</F=
ONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; om&gt;; from =
jdrosen@dynamicsoft.com on Tue, Jan 16, 2001 at 01:34:26AM -0500</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; On Tue, Jan 16, 2001 at =
01:34:26AM -0500, Jonathan Rosenberg wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; -----Original =
Message-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; From: Rick Dean [<A =
HREF=3D"mailto:siplist@fdd.com">mailto:siplist@fdd.com</A>]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; On Tue, Jan 09, 2001 =
at 01:25:41AM -0500, Jonathan Rosenberg wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">[snip]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; PSTN interoperability =
is paramount to me.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; Unfortunately, my =
calls need to work better</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; than 99% of the =
time.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">[snip]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Sure, if a gateway knows the far =
end is busy, it should send</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; a 486 busy -- no debate.&nbsp; =
If the gateway has unknown progress media</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; which might be busy-tone, =
ringback, or voice prompting; sending 200</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; OK helps manage the audio =
channel.&nbsp;&nbsp; Do you expect the human to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; hit a key on busy tone so his UA =
sends a CANCEL?&nbsp; or should</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; he just know to wait?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; I regret the 200 OK =
notion.&nbsp; With audio, I argue a session</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; is established.&nbsp; As a call =
originating UA, how to I suspend or</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; redirect the early media if my =
INVITE won't complete?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Sorry to be such as pain on this =
subject.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">[snip]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt;&nbsp; Hopefully, the =
gateway builders will</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; &gt; do the right =
thing.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Its not a question of lazy =
implementations. Its a question of not having</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; enough</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; information to send =
anything but early media.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">_______________________________________________</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">This list is for continuing =
development of the SIP protocol.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">The sip-implementer's list is the =
place to discuss implementation,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and to receive advice on =
understanding existing sip.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To subscribe to it, send mail to =
majordomo@cs.columbia.edu with</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;subscribe =
sip-implementors&quot; in the body.</FONT>
</P>
</UL></UL>
</BODY>
</HTML>
------_=_NextPart_001_01C080D6.346D9F50--

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 20:35:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00982
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 20:35:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 88DA14433B; Wed, 17 Jan 2001 19:36:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id A584F44336
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 19:35:23 -0500 (EST)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA29929;
	Wed, 17 Jan 2001 17:35:16 -0800 (PST)
Received: from buckthorn-nt.cisco.com (dhcp-128-107-142-87.cisco.com [128.107.142.87])
	by imop.cisco.com (Mirapoint)
	with ESMTP id AAH57422 (AUTH rmahy);
	Wed, 17 Jan 2001 17:34:55 -0800 (PST)
Message-Id: <5.0.0.25.2.20010117162639.01b82090@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
To: Rick Dean <siplist@fdd.com>
From: Rohan Mahy <rohan@cisco.com>
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
Cc: sip@lists.bell-labs.com
In-Reply-To: <20010117122634.A5496@fdd.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_13562321==_.ALT"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 17:33:45 -0800

--=====================_13562321==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Rick,

Thanks for preparing this so quickly.  A few questions are below.

-In section 5
>    The HANDOFF request may contain a body of MIME-type
>    application/sip-headers, which contains headers requested to be
>    copied into the spawned INVITE request.  For a HANDOFF request, the
>    "Refer-To" URI SHOULD NOT include question-mark delimited headers for
>    the subsequent INVITE.

What do you do if you get headers in the Refer-To (ignore, issue error x)?

>These headers SHOULD be copied to the
>    resulting INVITE without escaping processing.

By "These headers" do you mean the headers in the body or the headers that 
you SHOULD NOT put into the Refer-To URI?

>This MIME type MUST
>    NOT contain a header which begins with two dashes, "--".  This MIME
>    type MUST NOT include a call-id header, but instead use a "replaces"
>    header for this functionality.  This MIME type MUST NOT include a
>    "handoff" header.

What error should you return if you detect this stuff?

-The fact that you can have a "header body" and a session description 
implies multipart.  Do you really want to do that?

-The way you show the flows, the transferor sends the handoff, and then 
holds its call(s) up.  What happens if the transferee crashes after OKing 
the HANDOFF?  You would have to keep the call up "forever" 
right?  Presumably if the transferor wants to be rid of the call, it could 
send a BYE?

Take the following example where I begin an attended transfer, but I get 
tired of waiting.

A               B               C
INVITE ->
<- 180
<- 200
ACK ->

INVITE ------------->
<---------180--------

(several rings later)
HANDOFF ->
<- 200
                 INVITE ----->
                 replaces:
                 <--- 180 ----
<- NOTIFY
handoff-status: 180
200 ->
BYE ->
<- 200

-HANDOFF seeks to fill a much smaller role in the call control framework 
than some of us advocate for REFER. It seems you are advocating a framework 
with a larger number of more specific/smaller primitives.  PHONECTL would 
be one of these primitives.  What primitive (what would it look like in 
your version of hte framework) do you advocate to replace/unreplace 
yourself [as in the Music on Hold example I gave]?  How about a primitive 
for ad-hoc conferencing?

thanks,
-rohan

At 10:26 AM 1/17/01, Rick Dean wrote:

>Dear SIP list,
>
>Although we would like more time to
>edit this poor draft, we feel a sneak
>peek is warranted due to its urgent nature
>with the upcomming meeting.
>
>http://phonectl.sfour.com/draft-ietf-sip-handoff-00pre8.txt
>
>Some significant differences from REFER are:
>   * narrower scope
>   * method completes without prompting
>   * referred-by like header generated by transferee
>   * location of headers for spawned invite
>   * error processing & final notification
>
>Cheers,
>Rick
>rick_dean@3com.com
>
>
>_______________________________________________
>This list is for continuing development of the SIP protocol.
>The sip-implementer's list is the place to discuss implementation,
>and to receive advice on understanding existing sip.
>To subscribe to it, send mail to majordomo@cs.columbia.edu with
>"subscribe sip-implementors" in the body.


--=====================_13562321==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Rick,<br>
<br>
Thanks for preparing this so quickly.&nbsp; A few questions are
below.<br>
<br>
-In section 5<br>
<blockquote type=cite class=cite cite>&nbsp;&nbsp; The HANDOFF request
may contain a body of MIME-type<br>
&nbsp;&nbsp; application/sip-headers, which contains headers requested to
be<br>
&nbsp;&nbsp; copied into the spawned INVITE request.&nbsp; For a HANDOFF
request, the<br>
&nbsp;&nbsp; &quot;Refer-To&quot; URI SHOULD NOT include question-mark
delimited headers for<br>
&nbsp;&nbsp; the subsequent INVITE.&nbsp; </blockquote><br>
What do you do if you get headers in the Refer-To (ignore, issue error
x)?&nbsp; <br>
<br>
<blockquote type=cite class=cite cite>These headers SHOULD be copied to
the<br>
&nbsp;&nbsp; resulting INVITE without escaping processing.&nbsp;
</blockquote><br>
By &quot;These headers&quot; do you mean the headers in the body or the
headers that you SHOULD NOT put into the Refer-To URI?&nbsp; <br>
<br>
<blockquote type=cite class=cite cite>This MIME type MUST<br>
&nbsp;&nbsp; NOT contain a header which begins with two dashes,
&quot;--&quot;.&nbsp; This MIME<br>
&nbsp;&nbsp; type MUST NOT include a call-id header, but instead use a
&quot;replaces&quot;<br>
&nbsp;&nbsp; header for this functionality.&nbsp; This MIME type MUST NOT
include a<br>
&nbsp;&nbsp; &quot;handoff&quot; header.</blockquote><br>
What error should you return if you detect this stuff?<br>
<br>
-The fact that you can have a &quot;header body&quot; and a session
description implies multipart.&nbsp; Do you really want to do that?<br>
<br>
-The way you show the flows, the transferor sends the handoff, and then
holds its call(s) up.&nbsp; What happens if the transferee crashes after
OKing the HANDOFF?&nbsp; You would have to keep the call up
&quot;forever&quot; right?&nbsp; Presumably if the transferor wants to be
rid of the call, it could send a BYE?<br>
<br>
Take the following example where I begin an attended transfer, but I get
tired of waiting.&nbsp; <br>
<br>
<font face="Courier, Courier">A<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>B<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>C<br>
INVITE -&gt;<br>
&lt;- 180<br>
&lt;- 200<br>
ACK -&gt;<br>
<br>
INVITE -------------&gt;<br>
&lt;---------180--------<br>
<br>
(several rings later)<br>
HANDOFF -&gt;<br>
&lt;- 200<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>INVITE
-----&gt;<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>replaces:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&lt;---
180 ----<br>
&lt;- NOTIFY<br>
handoff-status: 180<br>
200 -&gt;<br>
BYE -&gt;<br>
&lt;- 200<br>
</font><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><br>
-HANDOFF seeks to fill a much smaller role in the call control framework
than some of us advocate for REFER. It seems you are advocating a
framework with a larger number of more specific/smaller primitives.&nbsp;
PHONECTL would be one of these primitives.&nbsp; What primitive (what
would it look like in your version of hte framework) do you advocate to
replace/unreplace yourself [as in the Music on Hold example I
gave]?&nbsp; How about a primitive for ad-hoc conferencing?<br>
<br>
thanks,<br>
-rohan<br>
<br>
At 10:26 AM 1/17/01, Rick Dean wrote:<br>
<br>
<blockquote type=cite class=cite cite>Dear SIP list,<br>
<br>
Although we would like more time to <br>
edit this poor draft, we feel a sneak<br>
peek is warranted due to its urgent nature<br>
with the upcomming meeting.<br>
<br>
<a href="http://phonectl.sfour.com/draft-ietf-sip-handoff-00pre8.txt" eudora="autourl">http://phonectl.sfour.com/draft-ietf-sip-handoff-00pre8.txt</a><br>
<br>
Some significant differences from REFER are:<br>
&nbsp; * narrower scope<br>
&nbsp; * method completes without prompting<br>
&nbsp; * referred-by like header generated by transferee<br>
&nbsp; * location of headers for spawned invite<br>
&nbsp; * error processing &amp; final notification<br>
<br>
Cheers,<br>
Rick<br>
rick_dean@3com.com<br>
<br>
<br>
_______________________________________________<br>
This list is for continuing development of the SIP protocol.<br>
The sip-implementer's list is the place to discuss implementation,<br>
and to receive advice on understanding existing sip.<br>
To subscribe to it, send mail to majordomo@cs.columbia.edu with<br>
&quot;subscribe sip-implementors&quot; in the body.</blockquote><br>
</html>

--=====================_13562321==_.ALT--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 20:58:05 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01440
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 20:58:05 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 634D44439B; Wed, 17 Jan 2001 19:58:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cybertron.div8.net (HSE-Kitchener-ppp194301.sympatico.ca [64.229.12.142])
	by lists.bell-labs.com (Postfix) with ESMTP id 93AD24433B
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 19:57:13 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m14J4LX-003EreC@cybertron.div8.net> (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Wed, 17 Jan 2001 20:58:39 -0500 (EST) 
From: Billy Biggs <billy@billybiggs.com>
To: Rohan Mahy <rohan@cisco.com>
Cc: Rick Dean <siplist@fdd.com>, SIP List <sip@lists.bell-labs.com>
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
Message-ID: <20010117205839.A1115@div8.net>
References: <20010117122634.A5496@fdd.com> <5.0.0.25.2.20010117162639.01b82090@imop.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.0.0.25.2.20010117162639.01b82090@imop.cisco.com>; from rohan@cisco.com on Wed, Jan 17, 2001 at 05:33:45PM -0800
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 20:58:39 -0500

Rohan Mahy (rohan@cisco.com):

> -In section 5
> >   The HANDOFF request may contain a body of MIME-type
> > application/sip-headers, which contains headers requested to be
> > copied into the spawned INVITE request.  For a HANDOFF request,
> > the "Refer-To" URI SHOULD NOT include question-mark delimited
> > headers for the subsequent INVITE.
> 
> What do you do if you get headers in the Refer-To (ignore, issue error
> x)?

  Any time a UA is asked to dial a URI with ?-headers, it has a choice
of whether or not to honour them.  The UA can do whatever it wants.

  Some implementations may choose not to honour them because of the
added complexity.  To accomodate this, we want to ask implementors to
place to-be-copied headers in an 'application/sip-headers' body to
decrease handoff failure.

> > These headers SHOULD be copied to the resulting INVITE without
> > escaping processing.
> 
> By "These headers" do you mean the headers in the body or the headers
> that you SHOULD NOT put into the Refer-To URI?

  We mean the headers in the body.  This text will be cleaned up,
thanks.

> > This MIME type MUST NOT contain a header which begins with two
> > dashes, "--".  This MIME type MUST NOT include a call-id header, but
> > instead use a "replaces" header for this functionality.  This MIME
> > type MUST NOT include a "handoff" header.
> 
> What error should you return if you detect this stuff?

  How about a 400, that's what it is for.  I would rather have
implementations ignore them.  This text will be cleaned up.

> - The fact that you can have a "header body" and a session description
>   implies multipart.  Do you really want to do that?

  I think so.

> -The way you show the flows, the transferor sends the handoff, and
>  then holds its call(s) up.  What happens if the transferee crashes
>  after OKing the HANDOFF?  You would have to keep the call up "forever"
>  right?  Presumably if the transferor wants to be rid of the call, it
>  could send a BYE?

  The transferor can have a timeout and send a BYE.  The transferee can
always call back later if it likes, implementation specific.  I'm not
worried.

> Take the following example where I begin an attended transfer, but I
> get tired of waiting.
> 
> [...]
> <- NOTIFY, handoff-status: 180
> 200 ->
> BYE ->
> <- 200

  I don't like this.  You're giving the transferor more information than
it needs.  This has security implications.  If you want to know the
progress of the call being setup, you should use a control protocol such
as PhoneControl.

> -HANDOFF seeks to fill a much smaller role in the call control
> framework than some of us advocate for REFER.

  Yes.

> It seems you are advocating a framework with a larger number of more
> specific/smaller primitives.

  Not necessarily.  Call handoff is a necessary primitive for building
many services.  I want it to be small and specific because we need
everyone to implement it.

> PHONECTL would be one of these primitives.  What primitive (what would
> it look like in your version of hte framework) do you advocate to
> replace/unreplace yourself [as in the Music on Hold example I gave]?

  If you want to replace/unreplace yourself, you need a strong control
protocol such as PhoneControl.

> How about a primitive for ad-hoc conferencing?

  This is a different problem.  In my opinion, ad-hoc conferencing needs
a higher protocol for negotiating setup and teardown of the individual
SIP sessions of the conference.

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 21:15:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01756
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 21:15:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C5E4C44391; Wed, 17 Jan 2001 20:16:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 4BC2D4433C
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 20:15:33 -0500 (EST)
Received: from nomsg.cisco.com (nomsg.cisco.com [171.71.163.24])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA10246;
	Wed, 17 Jan 2001 18:15:29 -0800 (PST)
Received: from cisco.com (dhcp-171-71-147-127.cisco.com [171.71.147.127])
	by nomsg.cisco.com (Mirapoint)
	with ESMTP id AAD14821 (AUTH caryfitz);
	Wed, 17 Jan 2001 18:52:06 -0800 (PST)
Message-ID: <3A6651A5.4F7F92ED@cisco.com>
From: Cary FitzGerald <caryfitz@cisco.com>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Rick Dean <siplist@fdd.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Back-to-back UAs
References: <20010116113721.A26496@fdd.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 18:15:01 -0800
Content-Transfer-Encoding: 7bit

Thinking about the 3pcc draft, it occurs to me that by not recording the fact that
we have passed through a 3pcc node (a 3pcc via, sort of), the 3pcc network element
is discarding useful information.  The same loop detection methods in standard SIP
could be reused.  This sort of looping is a could become a common problem in
cross-domain routing.  This sort of via is worth hiding.

Cary.

Rick Dean wrote:

> Keith,
>
> I apologize.  Back-to-back UA is another name for Rosenberg's
> 3rd Party Call Control.  3PCC was first published here..
> http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenberg-sip-3pcc-00.txt
> The draft does not use the B2BUA moniker.
>
> Yes, 3PCC/B2BUA can break the end to end nature.  Sometimes this
> is desired.  A company may wish to hide its internal
> routing.  A fragile gateway may need a SIP wrapper/firewall.  etc.
>
> The biggest problem I currently experience is
> looping.  I wish all B2BUAs would preserve
> the call-id.  Unfortunately, I can't get rid of my biggest
> B2BUA, the public switched telephony network (PSTN).  :-/
>
> --
> Rick
> rick_dean@3com.com
>
> On Tue, Jan 16, 2001 at 12:57:05PM -0000, Drage, Keith (Keith) wrote:
> > I keep seeing mention of back-to-back UAs and I think I understand what is
> > trying to be done with them.
> >
> > I do however see an issue that there is apparently no documentation of this
> > concept in any draft. Therefore it leads to the question of when does a
> > proxy become a back-to-back UA, and therefore perform all error handling and
> > syntactic checking as a UA rather than a proxy. Because there is no mention
> > in any draft, it would probably never be identified in any conformance
> > statement, and an attaching UA to this concept might therefore see behaviour
> > that was not expected.
> >
> > I also see problems where, because it is not documented, the impact of
> > interactions with other drafts may not have been assessed. For example, is
> > there an impact on the privacy draft, such that the identifiers passed using
> > the concepts of the privacy draft will never pass the back-to-back UA? Do we
> > have problems with any headers that have been ciphered, because we do not
> > wish to release them outside proxies?
> >
> > I would therefore ask, if such a concept is meant to legally exist, should
> > be not at least define it somewhere. (Thats assuming I haven't missed it
> > somewhere!)
> >
> > Keith Drage
> > Keith Drage
> > Lucent Technologies
> > Tel: +44 1793 776249
> > Email: drage@lucent.com
> >
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
>
> ----- End forwarded message -----
>
> _______________________________________________
> "This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip
> to subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body"


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 21:25:02 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01916
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 21:25:01 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D8C2A443AA; Wed, 17 Jan 2001 20:25:11 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id E0BDD44391
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 20:24:41 -0500 (EST)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <CKD5P0AX>; Wed, 17 Jan 2001 18:24:26 -0800
Message-ID: <E79883AEA37FD411A58C00508BAC5F4B2B5C81@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Cary FitzGerald'" <caryfitz@cisco.com>
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Back-to-back UAs
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C080F5.C6ADB6B0"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 18:24:25 -0800

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_01C080F5.C6ADB6B0
Content-Type: text/plain;
	charset="iso-8859-1"

Another fail-safe approach ....

As much as everybody hates the header, B2BUA's can make good use of
Max-Forwards. It will at least limit the number of loops that are possible.

Deterministic loop detection may not always be possible when two B2BUA's are
involved. However if the B2BUA decrements the Max-Forwards value each time a
call passes through it (or adds the header if it wasn't present on the input
side) then run-away looping is prevented.

Cheers,

Robert.

-- My opinions are my own and should not be taken as representing those of
Nuera Communications, Inc. -- 


		-----Original Message-----
		From:	Cary FitzGerald [mailto:caryfitz@cisco.com]
		Sent:	Thursday, January 18, 2001 1:15 PM
		To:	Rick Dean
		Cc:	sip@lists.bell-labs.com
		Subject:	Re: [SIP] Back-to-back UAs

		Thinking about the 3pcc draft, it occurs to me that by not
recording the fact that
		we have passed through a 3pcc node (a 3pcc via, sort of),
the 3pcc network element
		is discarding useful information.  The same loop detection
methods in standard SIP
		could be reused.  This sort of looping is a could become a
common problem in
		cross-domain routing.  This sort of via is worth hiding.

		Cary.

		Rick Dean wrote:

		> Keith,
		>
		> I apologize.  Back-to-back UA is another name for
Rosenberg's
		> 3rd Party Call Control.  3PCC was first published here..
		>
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenberg-sip-3pcc-00.txt
		> The draft does not use the B2BUA moniker.
		>
		> Yes, 3PCC/B2BUA can break the end to end nature.
Sometimes this
		> is desired.  A company may wish to hide its internal
		> routing.  A fragile gateway may need a SIP
wrapper/firewall.  etc.
		>
		> The biggest problem I currently experience is
		> looping.  I wish all B2BUAs would preserve
		> the call-id.  Unfortunately, I can't get rid of my biggest
		> B2BUA, the public switched telephony network (PSTN).  :-/
		>
		> --
		> Rick
		> rick_dean@3com.com
		>
		> On Tue, Jan 16, 2001 at 12:57:05PM -0000, Drage, Keith
(Keith) wrote:
		> > I keep seeing mention of back-to-back UAs and I think I
understand what is
		> > trying to be done with them.
		> >
		> > I do however see an issue that there is apparently no
documentation of this
		> > concept in any draft. Therefore it leads to the question
of when does a
		> > proxy become a back-to-back UA, and therefore perform
all error handling and
		> > syntactic checking as a UA rather than a proxy. Because
there is no mention
		> > in any draft, it would probably never be identified in
any conformance
		> > statement, and an attaching UA to this concept might
therefore see behaviour
		> > that was not expected.
		> >
		> > I also see problems where, because it is not documented,
the impact of
		> > interactions with other drafts may not have been
assessed. For example, is
		> > there an impact on the privacy draft, such that the
identifiers passed using
		> > the concepts of the privacy draft will never pass the
back-to-back UA? Do we
		> > have problems with any headers that have been ciphered,
because we do not
		> > wish to release them outside proxies?
		> >
		> > I would therefore ask, if such a concept is meant to
legally exist, should
		> > be not at least define it somewhere. (Thats assuming I
haven't missed it
		> > somewhere!)
		> >
		> > Keith Drage
		> > Keith Drage
		> > Lucent Technologies
		> > Tel: +44 1793 776249
		> > Email: drage@lucent.com
		> >
		> > _______________________________________________
		> > SIP mailing list
		> > SIP@lists.bell-labs.com
		> > http://lists.bell-labs.com/mailman/listinfo/sip
		>
		> ----- End forwarded message -----
		>
		> _______________________________________________
		> "This list is for continuing development of the SIP
protocol.
		> The sip-implementer's list is the place to discuss
implementation,
		> and to receive advice on understanding existing sip
		> to subscribe to it, send mail to majordomo@cs.columbia.edu
with
		> "subscribe sip-implementors" in the body"


		_______________________________________________
		This list is for continuing development of the SIP protocol.
		The sip-implementer's list is the place to discuss
implementation,
		and to receive advice on understanding existing sip.
		To subscribe to it, send mail to majordomo@cs.columbia.edu
with
		"subscribe sip-implementors" in the body.

------_=_NextPart_001_01C080F5.C6ADB6B0
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [SIP] Back-to-back UAs</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Another fail-safe approach ....</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">As much as everybody hates the header, =
B2BUA's can make good use of Max-Forwards. It will at least limit the =
number of loops that are possible.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Deterministic loop detection may not =
always be possible when two B2BUA's are involved. However if the B2BUA =
decrements the Max-Forwards value each time a call passes through it =
(or adds the header if it wasn't present on the input side) then =
run-away looping is prevented.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Cheers,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Robert.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-- My opinions are my own and should =
not be taken as representing those of Nuera Communications, Inc. -- =
</FONT>
</P>
<BR>
<UL><UL>
<P><A NAME=3D"_MailData"><FONT SIZE=3D2 FACE=3D"Arial">-----Original =
Message-----</FONT></A>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:&nbsp;&nbsp; Cary FitzGerald =
[<A =
HREF=3D"mailto:caryfitz@cisco.com">mailto:caryfitz@cisco.com</A>]</FONT>=
</B>
<BR><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D2 FACE=3D"Arial">Thursday, January 18, 2001 1:15 PM</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">Rick Dean</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D2 =
FACE=3D"Arial">sip@lists.bell-labs.com</FONT>
<BR><B><FONT SIZE=3D2 =
FACE=3D"Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D2 FACE=3D"Arial">Re: [SIP] Back-to-back UAs</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thinking about the 3pcc draft, it =
occurs to me that by not recording the fact that</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">we have passed through a 3pcc node (a =
3pcc via, sort of), the 3pcc network element</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">is discarding useful =
information.&nbsp; The same loop detection methods in standard =
SIP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">could be reused.&nbsp; This sort of =
looping is a could become a common problem in</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">cross-domain routing.&nbsp; This sort =
of via is worth hiding.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Cary.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Rick Dean wrote:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&gt; Keith,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; I apologize.&nbsp; Back-to-back =
UA is another name for Rosenberg's</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; 3rd Party Call Control.&nbsp; =
3PCC was first published here..</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; <A =
HREF=3D"http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenberg-sip-3=
pcc-00.txt" =
TARGET=3D"_blank">http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosen=
berg-sip-3pcc-00.txt</A></FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The draft does not use the B2BUA =
moniker.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Yes, 3PCC/B2BUA can break the =
end to end nature.&nbsp; Sometimes this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; is desired.&nbsp; A company may =
wish to hide its internal</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; routing.&nbsp; A fragile gateway =
may need a SIP wrapper/firewall.&nbsp; etc.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The biggest problem I currently =
experience is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; looping.&nbsp; I wish all B2BUAs =
would preserve</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; the call-id.&nbsp; =
Unfortunately, I can't get rid of my biggest</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; B2BUA, the public switched =
telephony network (PSTN).&nbsp; :-/</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; --</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; Rick</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; rick_dean@3com.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; On Tue, Jan 16, 2001 at =
12:57:05PM -0000, Drage, Keith (Keith) wrote:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; I keep seeing mention of =
back-to-back UAs and I think I understand what is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; trying to be done with =
them.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; I do however see an issue =
that there is apparently no documentation of this</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; concept in any draft. =
Therefore it leads to the question of when does a</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; proxy become a back-to-back =
UA, and therefore perform all error handling and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; syntactic checking as a UA =
rather than a proxy. Because there is no mention</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; in any draft, it would =
probably never be identified in any conformance</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; statement, and an attaching =
UA to this concept might therefore see behaviour</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; that was not =
expected.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; I also see problems where, =
because it is not documented, the impact of</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; interactions with other =
drafts may not have been assessed. For example, is</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; there an impact on the =
privacy draft, such that the identifiers passed using</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; the concepts of the privacy =
draft will never pass the back-to-back UA? Do we</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; have problems with any =
headers that have been ciphered, because we do not</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; wish to release them =
outside proxies?</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; I would therefore ask, if =
such a concept is meant to legally exist, should</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; be not at least define it =
somewhere. (Thats assuming I haven't missed it</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; somewhere!)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Keith Drage</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Keith Drage</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Lucent Technologies</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Tel: +44 1793 776249</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; Email: =
drage@lucent.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; SIP mailing list</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; =
SIP@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &gt; <A =
HREF=3D"http://lists.bell-labs.com/mailman/listinfo/sip" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></F=
ONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; ----- End forwarded message =
-----</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &quot;This list is for =
continuing development of the SIP protocol.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The sip-implementer's list is =
the place to discuss implementation,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; and to receive advice on understa=
nding existing sip</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; to subscribe to it, send mail to =
majordomo@cs.columbia.edu with</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; &quot;subscribe =
sip-implementors&quot; in the body&quot;</FONT>
</P>
<BR>

<P><FONT SIZE=3D2 =
FACE=3D"Arial">_______________________________________________</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">This list is for continuing =
development of the SIP protocol.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">The sip-implementer's list is the =
place to discuss implementation,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">and to receive advice on =
understanding existing sip.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">To subscribe to it, send mail to =
majordomo@cs.columbia.edu with</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;subscribe =
sip-implementors&quot; in the body.</FONT>
</P>
</UL></UL>
</BODY>
</HTML>
------_=_NextPart_001_01C080F5.C6ADB6B0--

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 21:34:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02945
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 21:34:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B3B07443B0; Wed, 17 Jan 2001 20:35:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 34BAF443AA
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 20:34:07 -0500 (EST)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA04389;
	Wed, 17 Jan 2001 18:34:07 -0800 (PST)
Received: from buckthorn-nt.cisco.com (dhcp-128-107-142-87.cisco.com [128.107.142.87])
	by imop.cisco.com (Mirapoint)
	with ESMTP id AAH58001 (AUTH rmahy);
	Wed, 17 Jan 2001 18:33:47 -0800 (PST)
Message-Id: <5.0.0.25.2.20010117182751.01b90d90@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0
To: Billy Biggs <billy@billybiggs.com>
From: Rohan Mahy <rohan@cisco.com>
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
Cc: Rohan Mahy <rohan@cisco.com>, Rick Dean <siplist@fdd.com>,
        SIP List <sip@lists.bell-labs.com>
In-Reply-To: <20010117205839.A1115@div8.net>
References: <5.0.0.25.2.20010117162639.01b82090@imop.cisco.com>
 <20010117122634.A5496@fdd.com>
 <5.0.0.25.2.20010117162639.01b82090@imop.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 18:31:59 -0800

At 05:58 PM 1/17/01, Billy Biggs wrote:
> > > This MIME type MUST NOT contain a header which begins with two
> > > dashes, "--".  This MIME type MUST NOT include a call-id header, but
> > > instead use a "replaces" header for this functionality.  This MIME
> > > type MUST NOT include a "handoff" header.
> >
> > What error should you return if you detect this stuff?
>
>   How about a 400, that's what it is for.  I would rather have
>implementations ignore them.  This text will be cleaned up.

presumably the transferor is trying to find/exploit a security loophole.

> > -HANDOFF seeks to fill a much smaller role in the call control
> > framework than some of us advocate for REFER.
>
>   Yes.
>
> > It seems you are advocating a framework with a larger number of more
> > specific/smaller primitives.
>
>   Not necessarily.  Call handoff is a necessary primitive for building
>many services.  I want it to be small and specific because we need
>everyone to implement it.
>
> > PHONECTL would be one of these primitives.  What primitive (what would
> > it look like in your version of hte framework) do you advocate to
> > replace/unreplace yourself [as in the Music on Hold example I gave]?
>
>   If you want to replace/unreplace yourself, you need a strong control
>protocol such as PhoneControl.

It is pretty standard stuff to replace yourself with someone/thing else and 
then be able to undo the replacement.  This doesn't usually imply the 
strong control relationship you would have with PHONECTL.

> > How about a primitive for ad-hoc conferencing?
>
>   This is a different problem.  In my opinion, ad-hoc conferencing needs
>a higher protocol for negotiating setup and teardown of the individual
>SIP sessions of the conference.

All fine and good, but what is it?




_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 17 21:52:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03118
	for <sip-archive@odin.ietf.org>; Wed, 17 Jan 2001 21:52:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 605AF443B1; Wed, 17 Jan 2001 20:53:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cybertron.div8.net (HSE-Kitchener-ppp194301.sympatico.ca [64.229.12.142])
	by lists.bell-labs.com (Postfix) with ESMTP id 9DEAA4439B
	for <sip@lists.bell-labs.com>; Wed, 17 Jan 2001 20:52:45 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m14J5DH-003EreC@cybertron.div8.net> (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Wed, 17 Jan 2001 21:54:11 -0500 (EST) 
From: Billy Biggs <billy@billybiggs.com>
To: Rohan Mahy <rohan@cisco.com>
Cc: Rick Dean <siplist@fdd.com>, SIP List <sip@lists.bell-labs.com>
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
Message-ID: <20010117215411.A1229@div8.net>
References: <5.0.0.25.2.20010117162639.01b82090@imop.cisco.com> <20010117122634.A5496@fdd.com> <5.0.0.25.2.20010117162639.01b82090@imop.cisco.com> <20010117205839.A1115@div8.net> <5.0.0.25.2.20010117182751.01b90d90@imop.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.0.0.25.2.20010117182751.01b90d90@imop.cisco.com>; from rohan@cisco.com on Wed, Jan 17, 2001 at 06:31:59PM -0800
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 21:54:11 -0500

Rohan Mahy (rohan@cisco.com):

> > > > This MIME type MUST NOT contain a header which begins with two
> > > > dashes, "--".  This MIME type MUST NOT include a call-id header,
> > > > but instead use a "replaces" header for this functionality.
> > > > This MIME type MUST NOT include a "handoff" header.
> > >
> > > What error should you return if you detect this stuff?
> >
> > How about a 400, that's what it is for.  I would rather have
> > implementations ignore them.  This text will be cleaned up.
> 
> presumably the transferor is trying to find/exploit a security
> loophole.

  If you think so, then return a 400.  Maybe you can have your UA call
911 automatically.  I'm unsure that it needs to be specified, it seems
implementation specific.  But as promised I will try and clean this up.

> > If you want to replace/unreplace yourself, you need a strong control
> > protocol such as PhoneControl.
> 
> It is pretty standard stuff to replace yourself with someone/thing
> else and then be able to undo the replacement.  This doesn't usually
> imply the strong control relationship you would have with PHONECTL.

  I'm unconvinced that replace/unreplace is standard stuff.  Your music
on hold example is much more easily (and properly) solved by having the
music-sending phone dial a music server and give it the far-end SDP
(3pcc/b2bua style).

> > > How about a primitive for ad-hoc conferencing?
> >
> > This is a different problem.  In my opinion, ad-hoc conferencing
> > needs a higher protocol for negotiating setup and teardown of the
> > individual SIP sessions of the conference.
> 
> All fine and good, but what is it?

  Wasn't there a BOF regarding ad-hoc/multiparty conferencing using SIP?
I was waiting for minutes, but never saw any.

  If you want my opinion, I can give it.  I did do some work researching
the topic.  We should really setup an egroups list or something to bang
on it.  There always seems to be interest in the topic...

  Regardless, there is definitely a seperate and specific need to
handoff a 3-way bridged call and connect the participants.  The HANDOFF
draft seeks to fill this gap.

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 02:02:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17014
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 02:02:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E55C74433B; Thu, 18 Jan 2001 01:03:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web10301.mail.yahoo.com (web10301.mail.yahoo.com [216.136.130.79])
	by lists.bell-labs.com (Postfix) with SMTP id C8E3144336
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 01:02:58 -0500 (EST)
Message-ID: <20010118070245.5637.qmail@web10301.mail.yahoo.com>
Received: from [203.200.4.38] by web10301.mail.yahoo.com; Wed, 17 Jan 2001 23:02:45 PST
From: james jack <sipjames@yahoo.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] About Also header
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 17 Jan 2001 23:02:45 -0800 (PST)

Dear all:
   I have one question to consult, now also header is
used in many drafts,I want to know will the also
header
be widely adopted by SIP industry?
   Any suggestions and ideas are welcome!
   Best Regards!
                      Yours: james

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 02:28:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20550
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 02:28:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9748F4433B; Thu, 18 Jan 2001 01:29:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from hindon.hss.co.in (unknown [202.54.26.202])
	by lists.bell-labs.com (Postfix) with ESMTP id 05FEB44336
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 01:28:14 -0500 (EST)
Received: from hsssun01.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id f0I7SkG27365;
	Thu, 18 Jan 2001 12:59:01 +0530 (IST)
Received: from sampark.hss.hns.com (sampark [139.85.229.22])
	by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id f0I7abk24890;
	Thu, 18 Jan 2001 13:06:43 +0530 (IST)
Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2  (651.2 6-10-1998))  id 652569D8.00291725 ; Thu, 18 Jan 2001 12:58:49 +0530
X-Lotus-FromDomain: HSSBLR
From: archow@hss.hns.com
To: james jack <sipjames@yahoo.com>
Cc: sip@lists.bell-labs.com
Message-ID: <652569D8.002915C8.00@sampark.hss.hns.com>
Subject: Re: [SIP] About Also header
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 18 Jan 2001 12:58:45 +0530



I believe Also header has now expired and has been depreciated.
Instead, the scope of Also is being broken up into more focussed areas
(like REFER for transfer).


regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems






james jack <sipjames@yahoo.com> on 01/18/2001 12:32:45 PM

To:   sip@lists.bell-labs.com
cc:

Subject:  [SIP] About Also header




Dear all:
   I have one question to consult, now also header is
used in many drafts,I want to know will the also
header
be widely adopted by SIP industry?
   Any suggestions and ideas are welcome!
   Best Regards!
                      Yours: james

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.





_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 02:56:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20801
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 02:56:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8397744389; Thu, 18 Jan 2001 01:57:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 1030B44336
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 01:56:13 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0I7u4107173;
	Thu, 18 Jan 2001 01:56:04 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: Rohan Mahy <rohan@cisco.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
Message-ID: <20010118015603.A10475@fdd.com>
References: <20010117122634.A5496@fdd.com> <5.0.0.25.2.20010117162639.01b82090@imop.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <5.0.0.25.2.20010117162639.01b82090@imop.cisco.com>; from rohan@cisco.com on Wed, Jan 17, 2001 at 05:33:45PM -0800
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 18 Jan 2001 01:56:04 -0600

On Wed, Jan 17, 2001 at 05:33:45PM -0800, Rohan Mahy wrote:
> Rick,
> 
> Thanks for preparing this so quickly.  A few questions are below.
> 
> -In section 5
> >    The HANDOFF request may contain a body of MIME-type
> >    application/sip-headers, which contains headers requested to be
> >    copied into the spawned INVITE request.  For a HANDOFF request, the
> >    "Refer-To" URI SHOULD NOT include question-mark delimited headers for
> >    the subsequent INVITE.
> 
> What do you do if you get headers in the Refer-To (ignore, issue error x)?

I am a byte slut. -- I would write the HANDOFF receiver however it 
turned out to be smallest.  The draft allows that.  My test scripts
would throw a big error if they receive it.  

What is your recomendation?  

> 
> >These headers SHOULD be copied to the
> >    resulting INVITE without escaping processing.
> 
> By "These headers" do you mean the headers in the body or the headers that 
> you SHOULD NOT put into the Refer-To URI?

ooops.  thanks.

> 
> >This MIME type MUST
> >    NOT contain a header which begins with two dashes, "--".  This MIME
> >    type MUST NOT include a call-id header, but instead use a "replaces"
> >    header for this functionality.  This MIME type MUST NOT include a
> >    "handoff" header.
> 
> What error should you return if you detect this stuff?
> 
> -The fact that you can have a "header body" and a session description 
> implies multipart.  Do you really want to do that?

The multipart is ugly.  I don't like the code for it.
People need to construct it carefully to fit it into one datagram.  

If I fanticized about syntax, I would ditch the 
multipart and place a second blank line after the spawned 
INVITE's headers, separating the true content-type body (SDP).
This won't be popular with the non-implementors. :-)

Actually, that is my second choice.  My first choice would
be a successful HANDOFF mutes audio, period.  (i.e. HANDOFF
response not handoff-status).  You need a re-INVITE if you 
want it back.   I predict this would be less popular.

What do you prefer?

> 
> -The way you show the flows, the transferor sends the handoff, and then 
> holds its call(s) up.  What happens if the transferee crashes after OKing 
> the HANDOFF?  You would have to keep the call up "forever" 
> right?  Presumably if the transferor wants to be rid of the call, it could 
> send a BYE?
>
> Take the following example where I begin an attended transfer, but I get 
> tired of waiting.
> 
> A               B               C
> INVITE ->
> <- 180
> <- 200
> ACK ->
> 
> INVITE ------------->
> <---------180--------
> 
> (several rings later)
> HANDOFF ->
> <- 200
>                  INVITE ----->
>                  replaces:
>                  <--- 180 ----
> <- NOTIFY
> handoff-status: 180
> 200 ->
> BYE ->
> <- 200

Yes, both sides can BYE early.  The handoff-status
mentioned "if the call-leg still exists" ...
but I can't find it now.  It will go back in.

Excellent suggestion.  Provisional handoff-statuses (statum?) 
should be explicitly allowed.  Although, my implementaion
might lie "handoff-status: 200 OK" when it
receives the 180 ringing, and BYE when it receives
a provisional handoff-status.  I still have more
testing to decide.

> 
> -HANDOFF seeks to fill a much smaller role in the call control framework 
> than some of us advocate for REFER. It seems you are advocating a framework 
> with a larger number of more specific/smaller primitives.  PHONECTL would 
> be one of these primitives.  

IMHO, SIP is for sessions.  With handoff
SIP is done.   If I can use SIP as a transport layer
for other protocols, I need nothing more from SIP.

Inbetween this ability to create sessions and
the PHONECTL API, sits the logic of a phone.  I like
this layered approach.  Can you think of any protocol
which tries to cross more network layers than SIP?  
Ironically, a SIP WG chair wouldn't consider the 
PHONECTL draft because he claimed it wasn't
in their mandate.

Thanks for the soapbox.

> What primitive (what would it look like in 
> your version of hte framework) do you advocate to replace/unreplace 
> yourself [as in the Music on Hold example I gave]?  

If the transferer wants to maintain control (like 
unreplace) then he should B2BUA.  If he works the SDP
correctly, he doesn't need to touch the media.
This is how I will do music-on-hold.  No contest.

The direct answer: no new primative.

> How about a primitive for ad-hoc conferencing?

Forgive me for not being sure of a definition for 
ad-hoc conferencing?  I am thinking it is when I, as
the middle of a three way call, move
it to a conference bridge to add more people.

1.  Call conference bridge.
2.  HANDOFF to conference bridge with "conference: call-id" 
    instead of "replaces: call-id"
3.  Phonectl to kick & mute.

Authentication for #1 determines billing.  The Phonectl passes
down that same call leg for authentication/simplicity.  The
conference bridge doesn't show its other independent meetings 
in the phonectl.  If new people want to join, they
call me, and I HANDOFF them in.  The server help is transparent
to the human.

I suppose this plan has the problem of other conference
members inviting more people themselves once they see the
"conference: call-id".  This could be
a feature for chained 3-way calls, and the billing contract 
might not make me pay for any guests I kick out within five 
seconds.

We will need to fix the mute stuff of PHONECTL.  

Cheers,
Rick
rick_dean@3com.com

> 
> thanks,
> -rohan
> 
> At 10:26 AM 1/17/01, Rick Dean wrote:
> 
> >Dear SIP list,
> >
> >Although we would like more time to
> >edit this poor draft, we feel a sneak
> >peek is warranted due to its urgent nature
> >with the upcomming meeting.
> >
> >http://phonectl.sfour.com/draft-ietf-sip-handoff-00pre8.txt
> >
> >Some significant differences from REFER are:
> >   * narrower scope
> >   * method completes without prompting
> >   * referred-by like header generated by transferee
> >   * location of headers for spawned invite
> >   * error processing & final notification
> >
> >Cheers,
> >Rick
> >rick_dean@3com.com
> >
> >
> >_______________________________________________
> >This list is for continuing development of the SIP protocol.
> >The sip-implementer's list is the place to discuss implementation,
> >and to receive advice on understanding existing sip.
> >To subscribe to it, send mail to majordomo@cs.columbia.edu with
> >"subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 05:17:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21690
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 05:17:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 421944433B; Thu, 18 Jan 2001 04:18:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.azisa.co.za (mail.azisa.co.za [196.14.124.43])
	by lists.bell-labs.com (Postfix) with ESMTP id 25DC744336
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 04:17:14 -0500 (EST)
Received: by MAIL with Internet Mail Service (5.5.2650.21)
	id <CXVXL34B>; Thu, 18 Jan 2001 12:19:19 +0200
Message-ID: <934C10A9A64AD4119440009027E099889A2CE7@MAIL>
From: Will van der Leij <wvdleij@azisa.co.za>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Terminating pending calls
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 18 Jan 2001 12:19:08 +0200

Hi,
My apologies if this has been covered somewhere in the archives,
I'm still scanning through them.

I have a question regarding the termination of pending INVITEs
without the possibility of the call being set up.
Consider sending an INVITE which gets a 200 OK response.
The UA decides, fow whatever reason, to drop the call. To do
this, the UA sends a BYE. The INVITE, however, needs to be
ACKed as well. Now if the BYE and ACK follow different routes,
then there is the possibility that the ACK arrives first and 
the call gets set up before the BYE terminates it.

Is there anything wrong with sending the BYE after receiving
the 200 OK for the INVITE and then only ACKing the INVITE after
receiving the 200 OK response to the BYE? The only draw back I 
can see here is that the server might retransmit the response 
before it receives the BYE. Or do we send them together?

I was also wondering why we need to send an ACK if we are going to
send a BYE for the call? Can the BYE, in such a case, not perform
the role of the ACK as far as the server is concerned?

Regards,
Will van der Leij

__________/\/^^^^^^\______
W.R.van der Leij
Azisa (Pty) Ltd.
http://www.azisa.co.za

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 05:53:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21850
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 05:53:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 443A54433B; Thu, 18 Jan 2001 04:54:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web10308.mail.yahoo.com (web10308.mail.yahoo.com [216.136.130.86])
	by lists.bell-labs.com (Postfix) with SMTP id 525E044336
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 04:53:15 -0500 (EST)
Message-ID: <20010118105301.82291.qmail@web10308.mail.yahoo.com>
Received: from [203.200.4.76] by web10308.mail.yahoo.com; Thu, 18 Jan 2001 02:53:01 PST
From: james jack <sipjames@yahoo.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] A foolish question on 3xx response.
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 18 Jan 2001 02:53:01 -0800 (PST)

Dear All:
   I have one question to consult, for example,
when a UA receive a 3xx response for INVITE with
multiple Contact headers, it will send 
INVITE requests to new address, then should these
new invite requests with new Call-ID?
   Thanks in advance!
   Best regards! 
                      Yours: James

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 07:06:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22264
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 07:06:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 985674433B; Thu, 18 Jan 2001 06:07:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60])
	by lists.bell-labs.com (Postfix) with ESMTP id 0402B44336
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 06:06:25 -0500 (EST)
Received: from cvis01.gpt.co.uk (unverified) by cvis28.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc363f43c512e34e6b4@cvis28.marconicomms.com>;
 Thu, 18 Jan 2001 12:06:09 +0000
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-30) id MAA10630; Thu, 18 Jan 2001 12:06:09 GMT
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 802569D8.00427471 ; Thu, 18 Jan 2001 12:05:51 +0000
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Keith Robinson" <Keith.Robinson@marconi.com>
To: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
Cc: "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>, sip@lists.bell-labs.com,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Message-ID: <802569D8.00427287.00@marconicomms.com>
Subject: RE: Outbound Proxies Renewed (was [SIP] Proxy Routing Logic)
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=3xAtnRLy49ODvifLyaTR2jloQ2LnMzDrcW5dwNUFtwPBd661f8QfmBSp"
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 18 Jan 2001 12:05:40 +0000

--0__=3xAtnRLy49ODvifLyaTR2jloQ2LnMzDrcW5dwNUFtwPBd661f8QfmBSp
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Going back to an earlier posting on this thread, Jacek Grabiec defined routing
procedure
that took into account chains of outbound proxies. I don't think that it is a
problem.

Regards,

K. Robinson







"Fairlie-Cuninghame, Robert" <rfairlie@nuera.com> on 17/01/2001 02:33:46
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:      "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>    
                                                              
 cc:      Keith Robinson/MAIN/MC1@MCMAIN,                     
          sip@lists.bell-labs.com, Jonathan Rosenberg         
          <jdrosen@dynamicsoft.com>                           
                                                              
                                                              
                                                              
 Subject: RE: Outbound Proxies Renewed (was [SIP] Proxy       
          Routing Logic)                                      
                                                              







Yes I agree Henning. In fact, that was one of the reasons I believe that
Keith's first option (a) [ie, the UA/proxy removing the next Route header
even if it doesn't route to it] is a risky idea. I think you may run into
problems when you get chains of outbound proxies, etc UA sends to outbound
proxy which in turn sends to another outbound proxy. In my mind the Route is
better left in place until it is actually used.

Cheers,

Robert.

-- My opinions are my own and should not be taken as representing those of
Nuera Communications, Inc. --

          -----Original Message-----
          From:     Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
          Sent:     Wednesday, January 17, 2001 12:21 PM
          To:  Fairlie-Cuninghame, Robert
          Cc:  'Keith Robinson'; sip@lists.bell-labs.com; Jonathan
Rosenberg
          Subject:  Re: Outbound Proxies Renewed (was [SIP]
Proxy Routing Logic)

          > "Fairlie-Cuninghame, Robert" wrote:
          >

          > I would also like to reiterate Jonathan's design goals for
a
          > solutions: that a proxy should not need to know whether it
is being
          > used as an outbound proxy or have to take special action
when being
          > used as a outbound proxy. The UA should be responsible for
taking any
          > action required (given that the UA is the only entity that
knows
          > whether it using a proxy as an "outbound proxy").

          Before we get into details, I want to make sure we don't
forget that
          proxy servers can also use outbound proxies, not just UAs.



          --
          Henning Schulzrinne   http://www.cs.columbia.edu/~hgs


--0__=3xAtnRLy49ODvifLyaTR2jloQ2LnMzDrcW5dwNUFtwPBd661f8QfmBSp
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U
PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+UkU6IE91
dGJvdW5kIFByb3hpZXMgUmVuZXdlZCAod2FzIFtTSVBdIFByb3h5IFJvdXRpbmcgTG9naWMpPC9U
SVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlll
cyBJIGFncmVlIEhlbm5pbmcuIEluIGZhY3QsIHRoYXQgd2FzIG9uZSBvZiB0aGUgcmVhc29ucyBJ
IGJlbGlldmUgdGhhdCBLZWl0aCdzIGZpcnN0IG9wdGlvbiAoYSkgW2llLCB0aGUgVUEvcHJveHkg
cmVtb3ZpbmcgdGhlIG5leHQgUm91dGUgaGVhZGVyIGV2ZW4gaWYgaXQgZG9lc24ndCByb3V0ZSB0
byBpdF0gaXMgYSByaXNreSBpZGVhLiBJIHRoaW5rIHlvdSBtYXkgcnVuIGludG8gcHJvYmxlbXMg
d2hlbiB5b3UgZ2V0IGNoYWlucyBvZiBvdXRib3VuZCBwcm94aWVzLCBldGMgVUEgc2VuZHMgdG8g
b3V0Ym91bmQgcHJveHkgd2hpY2ggaW4gdHVybiBzZW5kcyB0byBhbm90aGVyIG91dGJvdW5kIHBy
b3h5LiBJbiBteSBtaW5kIHRoZSBSb3V0ZSBpcyBiZXR0ZXIgbGVmdCBpbiBwbGFjZSB1bnRpbCBp
dCBpcyBhY3R1YWxseSB1c2VkLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+Q2hlZXJzLDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFs
Ij5Sb2JlcnQuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPi0t
IE15IG9waW5pb25zIGFyZSBteSBvd24gYW5kIHNob3VsZCBub3QgYmUgdGFrZW4gYXMgcmVwcmVz
ZW50aW5nIHRob3NlIG9mIE51ZXJhIENvbW11bmljYXRpb25zLCBJbmMuIC0tIDwvRk9OVD4NCjwv
UD4NCjxVTD48VUw+DQo8UD48QSBOQU1FPSJfTWFpbERhdGEiPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L0ZPTlQ+PC9BPg0KPEJSPjxCPjxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+RnJvbTombmJzcDsmbmJzcDsgSGVubmluZyBHLiBTY2h1bHpy
aW5uZSBbPEEgSFJFRj0ibWFpbHRvOmhnc0Bjcy5jb2x1bWJpYS5lZHUiPm1haWx0bzpoZ3NAY3Mu
Y29sdW1iaWEuZWR1PC9BPl08L0ZPTlQ+PC9CPg0KPEJSPjxCPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+U2VudDombmJzcDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPldlZG5lc2RheSwgSmFudWFyeSAxNywgMjAwMSAxMjoyMSBQTTwvRk9OVD4NCjxCUj48Qj48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlRvOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvRk9O
VD48L0I+IDxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+RmFpcmxpZS1DdW5pbmdoYW1lLCBSb2Jl
cnQ8L0ZPTlQ+DQo8QlI+PEI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5DYzombmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPidLZWl0
aCBSb2JpbnNvbic7IHNpcEBsaXN0cy5iZWxsLWxhYnMuY29tOyBKb25hdGhhbiBSb3NlbmJlcmc8
L0ZPTlQ+DQo8QlI+PEI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TdWJqZWN0OiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvRk9OVD48L0I+IDxGT05UIFNJWkU9
MiBGQUNFPSJBcmlhbCI+UmU6IE91dGJvdW5kIFByb3hpZXMgUmVuZXdlZCAod2FzIFtTSVBdIFBy
b3h5IFJvdXRpbmcgTG9naWMpPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0i
QXJpYWwiPiZndDsgJnF1b3Q7RmFpcmxpZS1DdW5pbmdoYW1lLCBSb2JlcnQmcXVvdDsgd3JvdGU6
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jmd0OyA8L0ZPTlQ+DQo8L1A+
DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jmd0OyBJIHdvdWxkIGFsc28gbGlrZSB0
byByZWl0ZXJhdGUgSm9uYXRoYW4ncyBkZXNpZ24gZ29hbHMgZm9yIGE8L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mZ3Q7IHNvbHV0aW9uczogdGhhdCBhIHByb3h5IHNob3Vs
ZCBub3QgbmVlZCB0byBrbm93IHdoZXRoZXIgaXQgaXMgYmVpbmc8L0ZPTlQ+DQo8QlI+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj4mZ3Q7IHVzZWQgYXMgYW4gb3V0Ym91bmQgcHJveHkgb3IgaGF2
ZSB0byB0YWtlIHNwZWNpYWwgYWN0aW9uIHdoZW4gYmVpbmc8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yIEZBQ0U9IkFyaWFsIj4mZ3Q7IHVzZWQgYXMgYSBvdXRib3VuZCBwcm94eS4gVGhlIFVBIHNo
b3VsZCBiZSByZXNwb25zaWJsZSBmb3IgdGFraW5nIGFueTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTIgRkFDRT0iQXJpYWwiPiZndDsgYWN0aW9uIHJlcXVpcmVkIChnaXZlbiB0aGF0IHRoZSBVQSBp
cyB0aGUgb25seSBlbnRpdHkgdGhhdCBrbm93czwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPiZndDsgd2hldGhlciBpdCB1c2luZyBhIHByb3h5IGFzIGFuICZxdW90O291dGJv
dW5kIHByb3h5JnF1b3Q7KS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+QmVmb3JlIHdlIGdldCBpbnRvIGRldGFpbHMsIEkgd2FudCB0byBtYWtlIHN1cmUgd2Ug
ZG9uJ3QgZm9yZ2V0IHRoYXQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5w
cm94eSBzZXJ2ZXJzIGNhbiBhbHNvIHVzZSBvdXRib3VuZCBwcm94aWVzLCBub3QganVzdCBVQXMu
IDwvRk9OVD4NCjwvUD4NCjxCUj4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFs
Ij4tLSA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5IZW5uaW5nIFNjaHVs
enJpbm5lJm5ic3A7Jm5ic3A7IDxBIEhSRUY9Imh0dHA6Ly93d3cuY3MuY29sdW1iaWEuZWR1L35o
Z3MiIFRBUkdFVD0iX2JsYW5rIj5odHRwOi8vd3d3LmNzLmNvbHVtYmlhLmVkdS9+aGdzPC9BPjwv
Rk9OVD4NCjwvUD4NCjwvVUw+PC9VTD4NCjwvQk9EWT4NCjwvSFRNTD4=

--0__=3xAtnRLy49ODvifLyaTR2jloQ2LnMzDrcW5dwNUFtwPBd661f8QfmBSp--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 07:08:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22300
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 07:08:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B7889443BB; Thu, 18 Jan 2001 06:09:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53])
	by lists.bell-labs.com (Postfix) with ESMTP id A5CAC443BA
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 06:08:22 -0500 (EST)
Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc363f435512e36e2f1@cvis21.Marconicomms.com> for <sip@lists.bell-labs.com>;
 Thu, 18 Jan 2001 12:08:19 +0000
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-30) id MAA11394; Thu, 18 Jan 2001 12:08:04 GMT
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 802569D8.0042A245 ; Thu, 18 Jan 2001 12:07:49 +0000
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Keith Robinson" <Keith.Robinson@marconi.com>
To: sip@lists.bell-labs.com
Message-ID: <802569D8.0042A02E.00@marconicomms.com>
Subject: Re: Outbound Proxies Renewed (was [SIP] Proxy Routing Logic)
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=qZ4RBtEIUeSqILvJ1q8hEbd4w2HEiu5q2JS17OuizWlK4jpCdWEJwnO5"
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 18 Jan 2001 12:07:35 +0000

--0__=qZ4RBtEIUeSqILvJ1q8hEbd4w2HEiu5q2JS17OuizWlK4jpCdWEJwnO5
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline




---------------------- Forwarded by Keith Robinson/MAIN/MC1 on 18/01/2001 12:07
---------------------------


18/01/2001 11:31
Keith Robinson


To:   "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com> @ MCEXT
cc:   sip@list.bell-labs.com, Jonathan Rosenberg <jdrosen@dynamicsoft.com>

Subject:  Re: Outbound Proxies Renewed (was [SIP] Proxy Routing Logic)
      (Document link: Keith Robinson)

Thanks for reply, even if you didn't agree !

Considering your proposal of placing the address of the proxy in the R-URI when
the UA is unable to do the Route mechanism because it lacks DNS; the following
R-URI may be received by the proxy (serving sipnet.com) in an initial INVITE

a) sip:userA@sipnet.com
b) sip:proxy.sipnet.com

For case a), the userA lies within the domain served by the proxy so the proxy
must
perform some type of location service to determine the physical endpoint to
which
to send the request.

For case b), the request is for the domain served by the proxy, but as there is
no user
identified it means that this must be a request from a UA that couldn't Route
using DNS
so the proxy must do the Routing for it; this suggests that the proxy is
inferring when it is
acting as an outbound poxy.

It appears, then, that the proxy must execute different logic for
R-URIs that identify the domain the proxy serves but have different formats (or
perhaps some
abstract user name for case (b), say outboundroutinglogic@sipnet.com) as opposed
to
always performing a location service when it receives an intial INVITE
identifying that
domain.

So, while I agree that this mechanism will, I think it still requires the proxy
to know when it is acting as an outbound proxy.

As a counterpoint, perhaps a proxy recognising it is being addressed as an
outbound proxy
and then following a set of standard procedures accordingly is not, in fact, the
wrong thing to do................

The most important point out of this is that the new Record-Route text needs to
identify exactly what
a UA, that can't or won't Route, puts in the R-URI and what it does with the
Route headers;
otherwise Record-Route is always going to be problematic when interoperating.

Regards,

K. Robinson.






"Fairlie-Cuninghame, Robert" <rfairlie@nuera.com> on 16/01/2001 10:36:41
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:      Keith Robinson/MAIN/MC1@MCMAIN                      
                                                              
 cc:      sip@lists.bell-labs.com, Jonathan Rosenberg         
          <jdrosen@dynamicsoft.com>                           
                                                              
                                                              
                                                              
 Subject: Outbound Proxies Renewed (was [SIP] Proxy Routing   
          Logic)                                              
                                                              







Trying to revive a stale unresolved thread ...

Keith Robinson wrote a very good synopsis of the problems but I disagree
with the conclusions drawn.

I would also like to reiterate Jonathan's design goals for a solutions: that
a proxy should not need to know whether it is being used as an outbound
proxy or have to take special action when being used as a outbound proxy.
The UA should be responsible for taking any action required (given that the
UA is the only entity that knows whether it using a proxy as an "outbound
proxy").

We seem to have two cases on the UA side:
1)   Does not have "Outbound Proxy" configured _or_ only needs to use
outbound proxy for SIP routing of initial request in a Call Leg.
2)   Needs to use outbound proxy for all SIP messages because it lacks
some ability. Eg DNS.

And we seem to have three cases on the proxy side. The proxy is
(unknowlingly) acting as a
1)   Normal proxy for UA, may or may not Record-Route.
2)   Outbound proxy for UA, no Record-Route needed [eg outbound proxy
only used for routing initial request]
3)   Outbound proxy for UA, needs to Record-route [eg. Firewall-like
proxy that must be used for all requests]

I am a proponent of Keith second course of action, that is, the UA does
_not_ strip the Route if it cannot use it (ie, UA case 2). [And Jonathan's
original suggestion]. However, I have a slight key modification! If the UA
sends a message without using the first Route header (assuming one exists),
then the request-URI is set to the outbound proxy's address !! eg
sip:proxy_address

Let me first say that I am not in favor of using Record-Routes of the form
Record-Route: original_request_uri;maddr=proxy_address.
Under the new record-route rules this should not be required. The "problem"
that Keith poses is a good example of why this form of record route is bad.
Whenever a Route header of this form is used, the maddr is often dropped. A
proxy that sees the request has no way of knowing whether the Request-URI is
due to a Route header that the proxy added itself (or not). In the first
case proxy should use the next route; otherwise I believe it should merely
forward the request to the Request-URI as written.

In my mind, it is this problem that causes the difficulties that are being
experienced.

The only problematic situation of all the above outbound proxy UA/proxy
permutations is when the proxy record routes _and_ the UA does not remove
the record route. (Proxy case 3 & UA case 2). So the first Route entry is
actually the Route header added by the outbound proxy- but now the
Request-URI will be equal to the proxy's address.

A proxy should not gobble/use the next Route header unless the Request-URI
specifies the proxy itself, right?  So it makes sense that when the proxy is
(unknowingly) acting as an outbound proxy _and_ the first record-routed
proxy that you might have to route/process a message twice (logically). The
UA inserted request-uri ensures that the message is routed to the outbound
proxy and that the proxy is able to use the next Route entry.

I don't see it as a problem that the proxy receives a request (to which it
is the target) and also finds itself in the first Route - it shouldn't break
things. Spiral routes included. The proxies need to differentiate multiple
Record-Routes for spiral routes in any case !! The first proxy should see
itself as the target of the Request-URI (due to UA's actions) which allows
the proxy to process the next Route header. Finding yourself as the next
recipient should not break things - its possible for this to occur with
spiral routes in any case, right?

This topic brings many of the currently contentious SIP issues out into the
open: Record-Route mechanism, maddr problems, transparent proxies and of
course outbound proxies. I'm sure many people will disagree but I thought I
would at least throw another cat among the pigeons.

Regards,

Robert.

-- My opinions are my own and should not be taken as representing those of
Nuera Communications, Inc. --

          -----Original Message-----
          From:     Keith Robinson [mailto:Keith.Robinson@marconi.com]
          Sent:     Thursday, January 04, 2001 3:42 AM
          To:  Jacek_Grabiec@3com.com
          Cc:  sip@lists.bell-labs.com; billy@billybiggs.com;
hgs@cs.columbia.edu; Jonathan Rosenberg; rfairlie@nuera.com;
jhornsby@ubiquity.net; vkg@lucent.com
          Subject:  RE: [SIP] Proxy Routing Logic



          The main conflict appears to be when a call stateful proxy,
which is acting as
          an outbound proxy for some UAs, record routes.
          The question for subsequent requests is who does the popping
of the first ROUTE
          entry into the R-URI ?

          For the UA, the two cases are :

          a) The UA pops the first route entry into the R-URI and
sends to its outbound
          proxy

          or

          b) The UA sends the request directly to its outbound proxy
without modifying the
          Route header and using, say, the URI in TO field as the
R-URI

          For case (a) the proxy (serving sipnet.com)  will see
something like the
          following
          (Assume the original request was addressed to
user1@anothernet.com)

          INVITE sip:user1@anothernet.com;maddr=proxy.sipnet.com

          the Route header may or may not be empty dependant on
whether further
          downstream proxies have record routed.

          For case (b) the proxy will receive something like

          INVITE sip:user1@anothernet.com
          Route: <sip:user1@anothernet.com;maddr=proxy.sipnet.com>

          Now,  for case (a), the request will be routed internally to
the appropriate
          call state machine
          using the R-URI, To, From and Call-Id headers. The request
will be processed and
          routed to the next server
          using information obtained from the original INVITE lookup,
stored CONTACT or
          the ROUTE header
          if present.

          For case (b) the request will be routed internally to the
appropriate call state
          machine as for
          case (a). The request will be processed and routed to the
next server using the
          ROUTE header
          which will send it back to the this proxy, identifying the
same call state
          machine as before; at best
          this will cause the request to be processed twice, at worst
it could cause
          problems with state,
          duplication of output etc,. The situation could be even
worse if the proxy uses
          rr-params to store state
          information to be returned in the R-URI, perhaps for
identifying spiralled call
          state machines.
          To stop this from happening, the proxy would have to perform
some look ahead
          processing on the
          Route header before deciding whether or not to actually use
the next Route
          entry, or merely
          remove it; this is special case processing on the usage of
the Route header and
          could become problematic if the proxy appears more than once
in the Route list
          due
          to spiralling.


          I therefore think that the UA should function as in case (a)
to eliminate the
          problems associated with
          case (b).

          Now, consider what happens when a UA operating as in case
(a) sends a subsequent
          request to
          its outbound proxy BUT the outbound proxy has deliberately
NOT record routed
          because it is not
          required to keep call state; however, two further downstream
proxies, serving
          nextsipnet.com and
          furthersipnet.com, HAVE record routed.

          The UA will have constructed a ROUTE header that looks
something like:

          Route: <sip:user2@nextsipnet.com;maddr=proxy.nextsipnet.com>
          Route:
<sip:user3@furthersipnet.com;maddr=proxy.furthersipnet.com>

          When the UA sends a subsequent INVITE, because it functions
as in case (a)
          it will pop the first Route entry into the R-URI, and send
this to its outbound
          proxy
          as it can't resolve proxy.nextsipnet.com because it has no
DNS capability.

          The proxy will receive the following :

          INVITE sip:user2@nextsipnet.com;maddr=proxy.nextsipnet.com
          Route:
<sip:user3@furthersipnet.com;maddr=proxy.furthersipnet.com>

          And this is the central point of the debate; should the
proxy route the above
          request by popping the first route entry into the R-URI, or
should it use
          the maddr in the R-URI received. In this case, the proxy
should clearly
          route the request using the maddr in the received R-URI,
otherwise
          proxy.nextsipnet.com will be bypassed even though it asked
to be kept
          in the path; this does, however, represent special case
processing dependant
          on the contents of the maddr.

          If the UA had functioned as in case (b) for the above
situation, then the proxy
          would need to route using the Route header.

          So, special case processing at the proxy appears unavoidable
no matter
          whether the UA functions as in case (a) or case (b), and
whether a proxy that is
          being used as an outbound proxy has record routed or not. I
think the question
          has
          to be is what special case processing is preferable and what
are  UA mandated to
          do with the Route header if they wish to use an outbound
proxy for subsequent
          requests.

          IMO, UAs using an outbound proxy should function as in case
(a) and proxies
          should look at the value of the received maddr before
deciding whether or not
          to route using the Route header if available. This provides
for the simplest
          rules; requiring the proxy to look at the entries in the
Route header before
          deciding
          if it can use the first entry (situation arising through
case (b) ) seems much
          more complex
          and prone to error.

          The text in 6.34.3 is unclear as to what a UA must do if it
is using an outbound
          proxy; I think
          it will lead to some UA functioning as in case (a) and some
as in case (b) which
          is the
          worst scenario as it becomes almost impossible for proxies
to know which
          processing
          to apply.

          Also, considering the above and continuing my previous point
on this thread
          about
          a roaming UA wishing to route through the context of its
home domain proxy I
          have the following in mind.

          A UA at visitednet.com has been given proxy.visited.net as
its local outbound
          proxy.
          The UA wishes to set up a call through its home domain proxy
to
          friend@anothernet.com.
          The UA may well construct a Route header to get to
proxy.homenet.com which looks
          like:

          Route <sip:friend@anothernet.com;maddr=proxy.homenet.com>

          Now, a UA that functions as in case (a) will send the
following to
          proxy.visitednet.com

          INVITE sip:friend@anothernet.com;maddr=proxy.homenet.com

          The Route header will be empty, as the UA has already popped
the entry
          into the R-URI.

          Upon receiving this request, proxy.visitednet.com (which
assumes all UA do case
          (a) )
          will see that the maddr refererences a domain not served by
itself and so
          forward the
          request to proxy.homenet.com, which will see the request:

          INVITE sip:friend@anothernet.com;maddr=proxy.homenet.com

          which is Billy's very first example on this thread.

          In this case I would want proxy.homenet.com to now route
using the URI
          friend@anothernet.com, which was my original point.

          If the UA functions as in case (b) then proxy.visitednet.com
(which assumes all
          UA do case (b) )
          receives

          INVITE sip:friend@anothernet.com
          Route: <sip:friend@anothernet.com;maddr=proxy.homenet.com>

          proxy.visitednet.com then pops the first Route entry into
the R-URI and forwards
          to proxy.homenet.com
          which receives the following

          INVITE sip:friend@anothernet.com;maddr=proxy.homenet.com

          which is exactly the same as if the UA/proxy were
functioning as in case (a).

          So, to summarise, assuming UAs function as in case (a), if a
proxy receives a
          R-URI
          with an maddr that does not reference the domain the proxy
serves then the proxy
          sends the request to that maddr, regardless of the Route
headers; if a proxy
          receives
          a R-URI with an maddr that does reference the domain it
serves then it strips
          the maddr
          and goes through the normal routing procedures. The only
special case processing
          is
          the result of checking the maddr.

          Regards,

          K. Robinson.




















          Jacek_Grabiec@3com.com on 02/01/2001 15:07:13














           To:      sip@lists.bell-labs.com



           cc:      billy@billybiggs.com, hgs@cs.columbia.edu,
Jonathan
                    Rosenberg <jdrosen@dynamicsoft.com>,

                    rfairlie@nuera.com, jhornsby@ubiquity.net,

                    vkg@lucent.com(bcc: Keith Robinson/MAIN/MC1)







           Subject: RE: [SIP] Proxy Routing Logic












          Jonathan Rosenberg wrote;
          >To comment on the primary issue, ignoring the Route header
if the request
          >URI domain is not your own, and sending it to that domain
first, is
          >dangerous, IMHO. Thats because, nearly as I can tell, it
completely breaks
          >the existing usage of record-routing. In the existing
usage, a proxy copies
          >the request URI in the request into the record-route, and
adds its own
          >maddr. Requests in the reverse direction will only get
routed correctly
          >through that same set of proxies IFF each proxy uses the
top route header no
          >matter what. If proxies start to only sometimes use them,
we will end up
          >with incorrectly routed requests.

          I'm not sure if 'ignoring the Route header if the request
          URI domain is not your own, and sending it to that domain
first' breaks
          anything.
          I can see it may add another proxy to the path, but at least
all record-routed
          Proxies are on the path as well. Doing otherwise will break
routing (I gave an
          example
          in one of my previuos postings). I would argue that proxy
cannot blindly follow
          logic 'replace RURI with Route' no matter what just like it
does not proxy
          responses
          downstream if top-via doesn't match the server - it checks
if it matches first.

          >So, I would modify my proposal to satisfy some of the other
requirements:

          >1. If there is a Route header in a request, that ALWAYS
takes priority for
          >routing the request.
          >2. If there is none, and the request URI has a domain NOT
matching that of
          >the server, but the address/domain in the maddr does, the
server forwards to
          >the domain in the userhost portion of the R-URI. If the
neither the maddr or
          >userhost have an ipaddress/domain matching the proxy, the
proxy sends the
          >request to the address in the maddr. Stripping of maddr is
optional.

          your 2 suggestion is really close what I would have in mind.
There's also
          another
          scenario: where Proxy receives a request with maddr where
neither maddr nor host
          portion of RURI matches the server.

          Let's say proxy at sip.company.com receives a requests like:

          sip:abc@someone-else.com;maddr=proxy.com
          .......
          Route:
<sip:123@yet-someone-else.com;maddr=yet-yet-someone-else.com>

          As Billy pointed out you, being the proxy, don't really want
to pop Route header
           blindly. I would rather
          propose something along theses lines - it is really close to
your 2 case (it
          also takes care of scenario where
          Proxy has it's own outbound Proxy which may have its own
outbound Proxy etc - if
           you were to pop Route at
          every hop the message would never get to the proper
Proxies):
          Investigate RURI first:
          1)   if maddr exist and it doesn't match your domain send
message to:
               - address indicated in maddr and strip maddr.
               - or, if outbound Proxy is used, to outbound Proxy and
preserve maddr
               - or, return 488 if unwilling/unable to forward the
request (I explained my
           reasoning for 488 in previous posting)
          2)   if maddr exist and it matches your domain strip maddr
and go to 3
          3)   if host part of RURI doesn't match your domain send
message to:
               - address indicated in host part of RURI and preserve
existing RURI and
          Route(s),
               - or, if outbound Proxy is used, to outbound Proxy and
preserve existing
          RURI and Route(s),
          4)   if host part of RURI does match your domain pop first
Route header and go
          back to 1
               (now your RURI is whatever Route header contained).
          5)   if there's no Route header do whatever you want (get
contact from your
               location/registrar server most likely) and go back to 1
(now RURI is
          whatever you got
               from location/registrar server)


          regards, Jacek Grabiec
          sip:jacek_grabiec@sip.3com.com



          _______________________________________________
          SIP mailing list
          SIP@lists.bell-labs.com
          http://lists.bell-labs.com/mailman/listinfo/sip




--0__=qZ4RBtEIUeSqILvJ1q8hEbd4w2HEiu5q2JS17OuizWlK4jpCdWEJwnO5
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U
PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1My4xMiI+DQo8VElUTEU+T3V0Ym91
bmQgUHJveGllcyBSZW5ld2VkICh3YXMgW1NJUF0gUHJveHkgUm91dGluZyBMb2dpYyk8L1RJVExF
Pg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+VHJ5aW5n
IHRvIHJldml2ZSBhIHN0YWxlIHVucmVzb2x2ZWQgdGhyZWFkIC4uLjwvRk9OVD4NCjwvUD4NCg0K
PFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5LZWl0aCBSb2JpbnNvbiB3cm90ZSBhIHZlcnkg
Z29vZCBzeW5vcHNpcyBvZiB0aGUgcHJvYmxlbXMgYnV0IEkgZGlzYWdyZWUgd2l0aCB0aGUgY29u
Y2x1c2lvbnMgZHJhd24uPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPkkgd291bGQgYWxzbyBsaWtlIHRvIHJlaXRlcmF0ZSBKb25hdGhhbidzIGRlc2lnbiBnb2Fs
cyBmb3IgYSBzb2x1dGlvbnM6IHRoYXQgYSBwcm94eSBzaG91bGQgbm90IG5lZWQgdG8ga25vdyB3
aGV0aGVyIGl0IGlzIGJlaW5nIHVzZWQgYXMgYW4gb3V0Ym91bmQgcHJveHkgb3IgaGF2ZSB0byB0
YWtlIHNwZWNpYWwgYWN0aW9uIHdoZW4gYmVpbmcgdXNlZCBhcyBhIG91dGJvdW5kIHByb3h5LiBU
aGUgVUEgc2hvdWxkIGJlIHJlc3BvbnNpYmxlIGZvciB0YWtpbmcgYW55IGFjdGlvbiByZXF1aXJl
ZCAoZ2l2ZW4gdGhhdCB0aGUgVUEgaXMgdGhlIG9ubHkgZW50aXR5IHRoYXQga25vd3Mgd2hldGhl
ciBpdCB1c2luZyBhIHByb3h5IGFzIGFuICJvdXRib3VuZCBwcm94eSIpLjwvRk9OVD48L1A+DQoN
CjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+V2Ugc2VlbSB0byBoYXZlPC9GT05UPiA8Rk9O
VCBTSVpFPTIgRkFDRT0iQXJpYWwiPnR3bzwvRk9OVD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
PiBjYXNlczwvRk9OVD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiBvbiB0aGUgVUE8L0ZPTlQ+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4gc2lkZTo8L0ZPTlQ+DQoNCjxPTCBUWVBFPTE+PExJ
PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+RG9lcyBub3QgaGF2ZTwvRk9OVD48Rk9OVCBTSVpF
PTIgRkFDRT0iQXJpYWwiPjwvRk9OVD4gPEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4iPC9GT05U
PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+T3V0Ym91bmQgUHJveHk8L0ZPTlQ+PEZPTlQgU0la
RT0yIEZBQ0U9IkFyaWFsIj4iPC9GT05UPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+PC9GT05U
PiA8Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmNvbmZpZ3VyZWQgXzwvRk9OVD48ST48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPm9yPC9GT05UPjwvST48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
Pl88L0ZPTlQ+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4gb25seSBuZWVkczwvRk9OVD4gPEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj50byB1c2U8L0ZPTlQ+IDxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+b3V0Ym91bmQgcHJveHkgZm9yIFNJUCByb3V0aW5nIG9mIGluaXRpYWwgcmVxdWVzdDwv
Rk9OVD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiBpbiBhIENhbGwgTGVnPC9GT05UPjxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+LjwvRk9OVD48L0xJPg0KPExJPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+TmVlZHM8L0ZPTlQ+IDxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+dG8gdXNlPC9G
T05UPiA8Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPm91dGJvdW5kIHByb3h5IGZvciBhbGwgU0lQ
PC9GT05UPiA8Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPm1lc3NhZ2VzPC9GT05UPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+IGJlY2F1c2UgaXQgbGFja3M8L0ZPTlQ+IDxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+c29tZSBhYmlsaXR5LiBFZzwvRk9OVD4gPEZPTlQgU0laRT0yIEZBQ0U9IkFy
aWFsIj5ETlMuPC9GT05UPjwvTEk+DQo8QlI+DQo8L09MPg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj5BbmQgdzwvRk9OVD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmUgc2VlbSB0byBo
YXZlIHRocmVlIGNhc2VzIG9uIHRoZSBwcm94eSBzaWRlPC9GT05UPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+LiBUaGUgcHJveHkgaXMgKHVua25vd2xpbmdseSkgYWN0aW5nIGFzIGE8L0ZPTlQ+
DQoNCjxPTCBUWVBFPTE+PExJPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Tm9ybWFsIHByb3h5
IGZvciBVQSwgbWF5IG9yIG1heSBub3QgUmVjb3JkLVJvdXRlLjwvRk9OVD48L0xJPg0KPExJPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+T3V0Ym91bmQgcHJveHkgZm9yIFVBLCBubyBSZWNvcmQt
Um91dGUgbmVlZGVkIFtlZyBvdXRib3VuZCBwcm94eSBvbmx5IHVzZWQgZm9yIHJvdXRpbmcgaW5p
dGlhbCByZXF1ZXN0XTwvRk9OVD48L0xJPg0KPExJPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
T3V0Ym91bmQgcHJveHkgZm9yIFVBLCBuZWVkcyB0byBSZWNvcmQtcm91dGUgW2VnLiBGaXJld2Fs
bC1saWtlIHByb3h5IHRoYXQgbXVzdCBiZSB1c2VkIGZvciBhbGwgcmVxdWVzdHNdPC9GT05UPjwv
TEk+DQo8QlI+DQo8L09MPg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JIGFtIGEgcHJv
cG9uZW50IG9mIEtlaXRoIHNlY29uZCBjb3Vyc2Ugb2YgYWN0aW9uLCB0aGF0IGlzLCB0aGUgVUEg
ZG9lczwvRk9OVD4gPEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5fPC9GT05UPjxJPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+bm90PC9GT05UPjwvST48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
Pl88L0ZPTlQ+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4gc3RyaXAgdGhlIFJvdXRlIGlmIGl0
IGNhbm5vdCB1c2UgaXQgKGllLCBVQSBjYXNlIDIpLiBbQW5kIEpvbmF0aGFuJ3Mgb3JpZ2luYWwg
c3VnZ2VzdGlvbl08L0ZPTlQ+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4uIEhvd2V2ZXIsIEkg
aGF2ZSBhIHNsaWdodCBrZXkgbW9kaWZpY2F0aW9uISBJZiB0aGUgVUEgc2VuZHMgYSBtZXNzYWdl
IHdpdGhvdXQgdXNpbmcgdGhlIGZpcnN0IFJvdXRlIGhlYWRlciAoYXNzdW1pbmcgb25lIGV4aXN0
cyksIHRoZW4gdGhlIHJlcXVlc3QtVVJJIGlzIHNldCB0byB0aGUgb3V0Ym91bmQgcHJveHkncyBh
ZGRyZXNzICEhIGVnIHNpcDpwcm94eV9hZGRyZXNzPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0la
RT0yIEZBQ0U9IkFyaWFsIj5MZXQgbWUgZmlyc3Qgc2F5IHRoYXQgSSBhbSBub3QgaW4gZmF2b3Ig
b2YgdXNpbmcgUmVjb3JkLVJvdXRlcyBvZiB0aGUgZm9ybTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTIgRkFDRT0iQXJpYWwiPlJlY29yZC1Sb3V0ZTo8L0ZPTlQ+PEk+IDxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+b3JpZ2luYWxfcmVxdWVzdF91cmk8L0ZPTlQ+PC9JPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+O21hZGRyPTwvRk9OVD48ST48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnByb3h5
X2FkZHJlc3M8L0ZPTlQ+PC9JPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+LiA8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5VbmRlciB0aGUgbmV3IHJlY29yZC1yb3V0ZSBy
dWxlcyB0aGlzIHNob3VsZCBub3QgYmUgcmVxdWlyZWQuIFRoZSAicHJvYmxlbSIgdGhhdCBLZWl0
aCBwb3NlcyBpcyBhIGdvb2QgZXhhbXBsZSBvZiB3aHkgdGhpcyBmb3JtIG9mIHJlY29yZCByb3V0
ZSBpcyBiYWQuIFdoZW5ldmVyIGEgUm91dGUgaGVhZGVyIG9mIHRoaXMgZm9ybSBpcyB1c2VkLCB0
aGUgbWFkZHIgaXMgb2Z0ZW4gZHJvcHBlZC4gQSBwcm94eSB0aGF0IHNlZXMgdGhlIHJlcXVlc3Qg
aGFzIG5vIHdheSBvZiBrbm93aW5nIHdoZXRoZXIgdGhlIFJlcXVlc3QtVVJJIGlzIGR1ZSB0byBh
IFJvdXRlIGhlYWRlciB0aGF0IHRoZSBwcm94eSBhZGRlZCBpdHNlbGYgKG9yIG5vdCkuIEluIHRo
ZSBmaXJzdCBjYXNlIHByb3h5IHNob3VsZCB1c2UgdGhlIG5leHQgcm91dGU7IG90aGVyd2lzZSBJ
IGJlbGlldmUgaXQgc2hvdWxkIG1lcmVseSBmb3J3YXJkIHRoZSByZXF1ZXN0IHRvIHRoZSBSZXF1
ZXN0LVVSSSBhcyB3cml0dGVuLjwvRk9OVD48L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+SW4gbXkgbWluZCwgaXQgaXMgdGhpcyBwcm9ibGVtIHRoYXQgY2F1c2VzIHRoZSBkaWZm
aWN1bHRpZXMgdGhhdCBhcmUgYmVpbmcgZXhwZXJpZW5jZWQuIDwvRk9OVD4NCjwvUD4NCg0KPFA+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UaGUgb25seSBwcm9ibGVtYXRpYyBzaXR1YXRpb24g
b2YgYWxsIHRoZSBhYm92ZSBvdXRib3VuZCBwcm94eSBVQS9wcm94eSBwZXJtdXRhdGlvbnMgaXMg
d2hlbiB0aGUgcHJveHkgcmVjb3JkIHJvdXRlcyBfPC9GT05UPjxJPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+YW5kPC9GT05UPjwvST48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPl8gdGhlIFVB
IGRvZXMgbm90IHJlbW92ZSB0aGUgcmVjb3JkIHJvdXRlLiAoUHJveHkgY2FzZSAzICZhbXA7IFVB
IGNhc2UgMikuIFNvIHRoZSBmaXJzdCBSb3V0ZSBlbnRyeSBpcyBhY3R1YWxseSB0aGUgUm91dGUg
aGVhZGVyIGFkZGVkIGJ5IHRoZSBvdXRib3VuZCBwcm94eS0gYnV0IG5vdyB0aGUgUmVxdWVzdC1V
Ukkgd2lsbCBiZSBlcXVhbCB0byB0aGUgcHJveHkncyBhZGRyZXNzLjwvRk9OVD48L1A+DQoNCjxQ
PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+QSBwcm94eSBzaG91bGQgbm90IGdvYmJsZS91c2Ug
dGhlIG5leHQgUm91dGUgaGVhZGVyIHVubGVzcyB0aGUgUmVxdWVzdC1VUkkgc3BlY2lmaWVzIHRo
ZSBwcm94eSBpdHNlbGYsIHJpZ2h0PyZuYnNwOyBTbyBpdCBtYWtlcyBzZW5zZSB0aGF0IHdoZW4g
dGhlIHByb3h5IGlzICh1bmtub3dpbmdseSkgYWN0aW5nIGFzIGFuIG91dGJvdW5kIHByb3h5IF9h
bmRfIHRoZSBmaXJzdCByZWNvcmQtcm91dGVkIHByb3h5IHRoYXQgeW91IG1pZ2h0IGhhdmUgdG8g
cm91dGUvcHJvY2VzcyBhIG1lc3NhZ2UgdHdpY2UgKGxvZ2ljYWxseSkuIFRoZSBVQSBpbnNlcnRl
ZCByZXF1ZXN0LXVyaSBlbnN1cmVzIHRoYXQgdGhlIG1lc3NhZ2UgaXMgcm91dGVkIHRvIHRoZSBv
dXRib3VuZCBwcm94eSBhbmQgdGhhdCB0aGUgcHJveHkgaXMgYWJsZSB0byB1c2UgdGhlIG5leHQg
Um91dGUgZW50cnkuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5J
IGRvbid0IHNlZSBpdCBhcyBhIHByb2JsZW0gdGhhdCB0aGUgcHJveHkgcmVjZWl2ZXMgYSByZXF1
ZXN0ICh0byB3aGljaCBpdCBpcyB0aGUgdGFyZ2V0KSBhbmQgYWxzbyBmaW5kcyBpdHNlbGYgaW4g
dGhlIGZpcnN0IFJvdXRlIC0gaXQgc2hvdWxkbid0IGJyZWFrIHRoaW5ncy4gU3BpcmFsIHJvdXRl
cyBpbmNsdWRlZC4gVGhlIHByb3hpZXMgbmVlZCB0byBkaWZmZXJlbnRpYXRlIG11bHRpcGxlIFJl
Y29yZC1Sb3V0ZXMgZm9yIHNwaXJhbCByb3V0ZXMgaW4gYW55IGNhc2UgISEgVGhlIGZpcnN0IHBy
b3h5IHNob3VsZCBzZWUgaXRzZWxmIGFzIHRoZSB0YXJnZXQgb2YgdGhlIFJlcXVlc3QtVVJJIChk
dWUgdG8gVUEncyBhY3Rpb25zKSB3aGljaCBhbGxvd3MgdGhlIHByb3h5IHRvIHByb2Nlc3MgdGhl
IG5leHQgUm91dGUgaGVhZGVyLiBGaW5kaW5nIHlvdXJzZWxmIGFzIHRoZSBuZXh0IHJlY2lwaWVu
dCBzaG91bGQgbm90IGJyZWFrIHRoaW5ncyAtIGl0cyBwb3NzaWJsZSBmb3IgdGhpcyB0byBvY2N1
ciB3aXRoIHNwaXJhbCByb3V0ZXMgaW4gYW55IGNhc2UsIHJpZ2h0PzwvRk9OVD48L1A+DQoNCjxQ
PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
MiBGQUNFPSJBcmlhbCI+VGhpcyB0b3BpYyBicmluZ3MgbWFueSBvZiB0aGUgY3VycmVudGx5IGNv
bnRlbnRpb3VzIFNJUCBpc3N1ZXMgb3V0IGludG8gdGhlIG9wZW46IFJlY29yZC1Sb3V0ZSBtZWNo
YW5pc20sIG1hZGRyIHByb2JsZW1zLCB0cmFuc3BhcmVudCBwcm94aWVzIGFuZCBvZiBjb3Vyc2Ug
b3V0Ym91bmQgcHJveGllcy4gSSdtIHN1cmUgbWFueSBwZW9wbGUgd2lsbCBkaXNhZ3JlZSBidXQg
SSB0aG91Z2h0IEkgd291bGQgYXQgbGVhc3QgdGhyb3cgYW5vdGhlciBjYXQgYW1vbmcgdGhlIHBp
Z2VvbnMuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5SZWdhcmRz
LDwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Sb2JlcnQuPC9G
T05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPi0tIE15IG9waW5pb25z
IGFyZSBteSBvd24gYW5kIHNob3VsZCBub3QgYmUgdGFrZW4gYXMgcmVwcmVzZW50aW5nIHRob3Nl
IG9mIE51ZXJhIENvbW11bmljYXRpb25zLCBJbmMuIC0tPC9GT05UPg0KPC9QPg0KPFVMPjxVTD4N
CjxQPjxBIE5BTUU9Il9NYWlsRGF0YSI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4tLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD48L0E+DQo8QlI+PEI+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj5Gcm9tOiZuYnNwOyZuYnNwOyBLZWl0aCBSb2JpbnNvbiBbPEEgSFJFRj0ibWFpbHRv
OktlaXRoLlJvYmluc29uQG1hcmNvbmkuY29tIj5tYWlsdG86S2VpdGguUm9iaW5zb25AbWFyY29u
aS5jb208L0E+XTwvRk9OVD48L0I+DQo8QlI+PEI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5T
ZW50OiZuYnNwOyZuYnNwOzwvRk9OVD48L0I+IDxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+VGh1
cnNkYXksIEphbnVhcnkgMDQsIDIwMDEgMzo0MiBBTTwvRk9OVD4NCjxCUj48Qj48Rk9OVCBTSVpF
PTIgRkFDRT0iQXJpYWwiPlRvOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvRk9OVD48L0I+IDxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SmFjZWtfR3JhYmllY0AzY29tLmNvbTwvRk9OVD4NCjxC
Uj48Qj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkNjOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OzwvRk9OVD48L0I+IDxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+c2lwQGxpc3RzLmJlbGwtbGFi
cy5jb207IGJpbGx5QGJpbGx5YmlnZ3MuY29tOyBoZ3NAY3MuY29sdW1iaWEuZWR1OyBKb25hdGhh
biBSb3NlbmJlcmc7IHJmYWlybGllQG51ZXJhLmNvbTsgamhvcm5zYnlAdWJpcXVpdHkubmV0OyB2
a2dAbHVjZW50LmNvbTwvRk9OVD48L1A+DQoNCjxQPjxCPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlh
bCI+U3ViamVjdDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L0ZP
TlQ+PC9CPiA8Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlJFOiBbU0lQXSBQcm94eSBSb3V0aW5n
IExvZ2ljPC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0i
QXJpYWwiPlRoZSBtYWluIGNvbmZsaWN0IGFwcGVhcnMgdG8gYmUgd2hlbiBhIGNhbGwgc3RhdGVm
dWwgcHJveHksIHdoaWNoIGlzIGFjdGluZyBhczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPmFuIG91dGJvdW5kIHByb3h5IGZvciBzb21lIFVBcywgcmVjb3JkIHJvdXRlcy48
L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UaGUgcXVlc3Rpb24gZm9yIHN1
YnNlcXVlbnQgcmVxdWVzdHMgaXMgd2hvIGRvZXMgdGhlIHBvcHBpbmcgb2YgdGhlIGZpcnN0IFJP
VVRFPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+ZW50cnkgaW50byB0aGUg
Ui1VUkkgPzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Gb3Ig
dGhlIFVBLCB0aGUgdHdvIGNhc2VzIGFyZSA6PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpF
PTIgRkFDRT0iQXJpYWwiPmEpIFRoZSBVQSBwb3BzIHRoZSBmaXJzdCByb3V0ZSBlbnRyeSBpbnRv
IHRoZSBSLVVSSSBhbmQgc2VuZHMgdG8gaXRzIG91dGJvdW5kPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+cHJveHk8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+b3I8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlh
bCI+YikgVGhlIFVBIHNlbmRzIHRoZSByZXF1ZXN0IGRpcmVjdGx5IHRvIGl0cyBvdXRib3VuZCBw
cm94eSB3aXRob3V0IG1vZGlmeWluZyB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj5Sb3V0ZSBoZWFkZXIgYW5kIHVzaW5nLCBzYXksIHRoZSBVUkkgaW4gVE8gZmllbGQg
YXMgdGhlIFItVVJJPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
PkZvciBjYXNlIChhKSB0aGUgcHJveHkgKHNlcnZpbmcgc2lwbmV0LmNvbSkmbmJzcDsgd2lsbCBz
ZWUgc29tZXRoaW5nIGxpa2UgdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlh
bCI+Zm9sbG93aW5nPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+KEFzc3Vt
ZSB0aGUgb3JpZ2luYWwgcmVxdWVzdCB3YXMgYWRkcmVzc2VkIHRvIHVzZXIxQGFub3RoZXJuZXQu
Y29tKTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JTlZJVEUg
c2lwOnVzZXIxQGFub3RoZXJuZXQuY29tO21hZGRyPXByb3h5LnNpcG5ldC5jb208L0ZPTlQ+DQo8
L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+dGhlIFJvdXRlIGhlYWRlciBtYXkg
b3IgbWF5IG5vdCBiZSBlbXB0eSBkZXBlbmRhbnQgb24gd2hldGhlciBmdXJ0aGVyPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+ZG93bnN0cmVhbSBwcm94aWVzIGhhdmUgcmVj
b3JkIHJvdXRlZC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
Rm9yIGNhc2UgKGIpIHRoZSBwcm94eSB3aWxsIHJlY2VpdmUgc29tZXRoaW5nIGxpa2U8L0ZPTlQ+
DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SU5WSVRFIHNpcDp1c2VyMUBh
bm90aGVybmV0LmNvbTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlJvdXRl
OiAmbHQ7c2lwOnVzZXIxQGFub3RoZXJuZXQuY29tO21hZGRyPXByb3h5LnNpcG5ldC5jb20mZ3Q7
PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPk5vdywmbmJzcDsg
Zm9yIGNhc2UgKGEpLCB0aGUgcmVxdWVzdCB3aWxsIGJlIHJvdXRlZCBpbnRlcm5hbGx5IHRvIHRo
ZSBhcHByb3ByaWF0ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmNhbGwg
c3RhdGUgbWFjaGluZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnVzaW5n
IHRoZSBSLVVSSSwgVG8sIEZyb20gYW5kIENhbGwtSWQgaGVhZGVycy4gVGhlIHJlcXVlc3Qgd2ls
bCBiZSBwcm9jZXNzZWQgYW5kPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
cm91dGVkIHRvIHRoZSBuZXh0IHNlcnZlcjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0i
QXJpYWwiPnVzaW5nIGluZm9ybWF0aW9uIG9idGFpbmVkIGZyb20gdGhlIG9yaWdpbmFsIElOVklU
RSBsb29rdXAsIHN0b3JlZCBDT05UQUNUIG9yPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+dGhlIFJPVVRFIGhlYWRlcjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0i
QXJpYWwiPmlmIHByZXNlbnQuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0i
QXJpYWwiPkZvciBjYXNlIChiKSB0aGUgcmVxdWVzdCB3aWxsIGJlIHJvdXRlZCBpbnRlcm5hbGx5
IHRvIHRoZSBhcHByb3ByaWF0ZSBjYWxsIHN0YXRlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+bWFjaGluZSBhcyBmb3I8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj5jYXNlIChhKS4gVGhlIHJlcXVlc3Qgd2lsbCBiZSBwcm9jZXNzZWQgYW5kIHJvdXRl
ZCB0byB0aGUgbmV4dCBzZXJ2ZXIgdXNpbmcgdGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+Uk9VVEUgaGVhZGVyPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+d2hpY2ggd2lsbCBzZW5kIGl0IGJhY2sgdG8gdGhlIHRoaXMgcHJveHksIGlkZW50aWZ5
aW5nIHRoZSBzYW1lIGNhbGwgc3RhdGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFy
aWFsIj5tYWNoaW5lIGFzIGJlZm9yZTsgYXQgYmVzdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIg
RkFDRT0iQXJpYWwiPnRoaXMgd2lsbCBjYXVzZSB0aGUgcmVxdWVzdCB0byBiZSBwcm9jZXNzZWQg
dHdpY2UsIGF0IHdvcnN0IGl0IGNvdWxkIGNhdXNlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+cHJvYmxlbXMgd2l0aCBzdGF0ZSw8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
IEZBQ0U9IkFyaWFsIj5kdXBsaWNhdGlvbiBvZiBvdXRwdXQgZXRjLC4gVGhlIHNpdHVhdGlvbiBj
b3VsZCBiZSBldmVuIHdvcnNlIGlmIHRoZSBwcm94eSB1c2VzPC9GT05UPg0KPEJSPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+cnItcGFyYW1zIHRvIHN0b3JlIHN0YXRlPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+aW5mb3JtYXRpb24gdG8gYmUgcmV0dXJuZWQgaW4gdGhl
IFItVVJJLCBwZXJoYXBzIGZvciBpZGVudGlmeWluZyBzcGlyYWxsZWQgY2FsbDwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnN0YXRlIG1hY2hpbmVzLjwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlRvIHN0b3AgdGhpcyBmcm9tIGhhcHBlbmluZywgdGhl
IHByb3h5IHdvdWxkIGhhdmUgdG8gcGVyZm9ybSBzb21lIGxvb2sgYWhlYWQ8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5wcm9jZXNzaW5nIG9uIHRoZTwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlJvdXRlIGhlYWRlciBiZWZvcmUgZGVjaWRpbmcgd2hl
dGhlciBvciBub3QgdG8gYWN0dWFsbHkgdXNlIHRoZSBuZXh0IFJvdXRlPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+ZW50cnksIG9yIG1lcmVseTwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTIgRkFDRT0iQXJpYWwiPnJlbW92ZSBpdDsgdGhpcyBpcyBzcGVjaWFsIGNhc2UgcHJv
Y2Vzc2luZyBvbiB0aGUgdXNhZ2Ugb2YgdGhlIFJvdXRlIGhlYWRlciBhbmQ8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5jb3VsZCBiZWNvbWUgcHJvYmxlbWF0aWMgaWYgdGhl
IHByb3h5IGFwcGVhcnMgbW9yZSB0aGFuIG9uY2UgaW4gdGhlIFJvdXRlIGxpc3Q8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5kdWU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
IEZBQ0U9IkFyaWFsIj50byBzcGlyYWxsaW5nLjwvRk9OVD4NCjwvUD4NCjxCUj4NCg0KPFA+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JIHRoZXJlZm9yZSB0aGluayB0aGF0IHRoZSBVQSBzaG91
bGQgZnVuY3Rpb24gYXMgaW4gY2FzZSAoYSkgdG8gZWxpbWluYXRlIHRoZTwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnByb2JsZW1zIGFzc29jaWF0ZWQgd2l0aDwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmNhc2UgKGIpLjwvRk9OVD4NCjwvUD4NCg0K
PFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Ob3csIGNvbnNpZGVyIHdoYXQgaGFwcGVucyB3
aGVuIGEgVUEgb3BlcmF0aW5nIGFzIGluIGNhc2UgKGEpIHNlbmRzIGEgc3Vic2VxdWVudDwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnJlcXVlc3QgdG88L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5pdHMgb3V0Ym91bmQgcHJveHkgQlVUIHRoZSBvdXRi
b3VuZCBwcm94eSBoYXMgZGVsaWJlcmF0ZWx5IE5PVCByZWNvcmQgcm91dGVkPC9GT05UPg0KPEJS
PjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+YmVjYXVzZSBpdCBpcyBub3Q8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5yZXF1aXJlZCB0byBrZWVwIGNhbGwgc3RhdGU7IGhv
d2V2ZXIsIHR3byBmdXJ0aGVyIGRvd25zdHJlYW0gcHJveGllcywgc2VydmluZzwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPm5leHRzaXBuZXQuY29tIGFuZDwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmZ1cnRoZXJzaXBuZXQuY29tLCBIQVZFIHJlY29y
ZCByb3V0ZWQuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlRo
ZSBVQSB3aWxsIGhhdmUgY29uc3RydWN0ZWQgYSBST1VURSBoZWFkZXIgdGhhdCBsb29rcyBzb21l
dGhpbmcgbGlrZTo8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
Um91dGU6ICZsdDtzaXA6dXNlcjJAbmV4dHNpcG5ldC5jb207bWFkZHI9cHJveHkubmV4dHNpcG5l
dC5jb20mZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Um91dGU6ICZs
dDtzaXA6dXNlcjNAZnVydGhlcnNpcG5ldC5jb207bWFkZHI9cHJveHkuZnVydGhlcnNpcG5ldC5j
b20mZ3Q7PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPldoZW4g
dGhlIFVBIHNlbmRzIGEgc3Vic2VxdWVudCBJTlZJVEUsIGJlY2F1c2UgaXQgZnVuY3Rpb25zIGFz
IGluIGNhc2UgKGEpPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+aXQgd2ls
bCBwb3AgdGhlIGZpcnN0IFJvdXRlIGVudHJ5IGludG8gdGhlIFItVVJJLCBhbmQgc2VuZCB0aGlz
IHRvIGl0cyBvdXRib3VuZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnBy
b3h5PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+YXMgaXQgY2FuJ3QgcmVz
b2x2ZSBwcm94eS5uZXh0c2lwbmV0LmNvbSBiZWNhdXNlIGl0IGhhcyBubyBETlMgY2FwYWJpbGl0
eS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+VGhlIHByb3h5
IHdpbGwgcmVjZWl2ZSB0aGUgZm9sbG93aW5nIDo8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+SU5WSVRFIHNpcDp1c2VyMkBuZXh0c2lwbmV0LmNvbTttYWRkcj1w
cm94eS5uZXh0c2lwbmV0LmNvbTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
PlJvdXRlOiAmbHQ7c2lwOnVzZXIzQGZ1cnRoZXJzaXBuZXQuY29tO21hZGRyPXByb3h5LmZ1cnRo
ZXJzaXBuZXQuY29tJmd0OzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFy
aWFsIj5BbmQgdGhpcyBpcyB0aGUgY2VudHJhbCBwb2ludCBvZiB0aGUgZGViYXRlOyBzaG91bGQg
dGhlIHByb3h5IHJvdXRlIHRoZSBhYm92ZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0i
QXJpYWwiPnJlcXVlc3QgYnkgcG9wcGluZyB0aGUgZmlyc3Qgcm91dGUgZW50cnkgaW50byB0aGUg
Ui1VUkksIG9yIHNob3VsZCBpdCB1c2U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFy
aWFsIj50aGUgbWFkZHIgaW4gdGhlIFItVVJJIHJlY2VpdmVkLiBJbiB0aGlzIGNhc2UsIHRoZSBw
cm94eSBzaG91bGQgY2xlYXJseTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
PnJvdXRlIHRoZSByZXF1ZXN0IHVzaW5nIHRoZSBtYWRkciBpbiB0aGUgcmVjZWl2ZWQgUi1VUkks
IG90aGVyd2lzZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnByb3h5Lm5l
eHRzaXBuZXQuY29tIHdpbGwgYmUgYnlwYXNzZWQgZXZlbiB0aG91Z2ggaXQgYXNrZWQgdG8gYmUg
a2VwdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmluIHRoZSBwYXRoOyB0
aGlzIGRvZXMsIGhvd2V2ZXIsIHJlcHJlc2VudCBzcGVjaWFsIGNhc2UgcHJvY2Vzc2luZyBkZXBl
bmRhbnQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5vbiB0aGUgY29udGVu
dHMgb2YgdGhlIG1hZGRyLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFy
aWFsIj5JZiB0aGUgVUEgaGFkIGZ1bmN0aW9uZWQgYXMgaW4gY2FzZSAoYikgZm9yIHRoZSBhYm92
ZSBzaXR1YXRpb24sIHRoZW4gdGhlIHByb3h5PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+d291bGQgbmVlZCB0byByb3V0ZSB1c2luZyB0aGUgUm91dGUgaGVhZGVyLjwvRk9O
VD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Tbywgc3BlY2lhbCBjYXNl
IHByb2Nlc3NpbmcgYXQgdGhlIHByb3h5IGFwcGVhcnMgdW5hdm9pZGFibGUgbm8gbWF0dGVyPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+d2hldGhlciB0aGUgVUEgZnVuY3Rp
b25zIGFzIGluIGNhc2UgKGEpIG9yIGNhc2UgKGIpLCBhbmQgd2hldGhlciBhIHByb3h5IHRoYXQg
aXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5iZWluZyB1c2VkIGFzIGFu
IG91dGJvdW5kIHByb3h5IGhhcyByZWNvcmQgcm91dGVkIG9yIG5vdC4gSSB0aGluayB0aGUgcXVl
c3Rpb248L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5oYXM8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj50byBiZSBpcyB3aGF0IHNwZWNpYWwgY2FzZSBw
cm9jZXNzaW5nIGlzIHByZWZlcmFibGUgYW5kIHdoYXQgYXJlJm5ic3A7IFVBIG1hbmRhdGVkIHRv
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+ZG8gd2l0aCB0aGUgUm91dGUg
aGVhZGVyIGlmIHRoZXkgd2lzaCB0byB1c2UgYW4gb3V0Ym91bmQgcHJveHkgZm9yIHN1YnNlcXVl
bnQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5yZXF1ZXN0cy48L0ZPTlQ+
DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SU1PLCBVQXMgdXNpbmcgYW4g
b3V0Ym91bmQgcHJveHkgc2hvdWxkIGZ1bmN0aW9uIGFzIGluIGNhc2UgKGEpIGFuZCBwcm94aWVz
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+c2hvdWxkIGxvb2sgYXQgdGhl
IHZhbHVlIG9mIHRoZSByZWNlaXZlZCBtYWRkciBiZWZvcmUgZGVjaWRpbmcgd2hldGhlciBvciBu
b3Q8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj50byByb3V0ZSB1c2luZyB0
aGUgUm91dGUgaGVhZGVyIGlmIGF2YWlsYWJsZS4gVGhpcyBwcm92aWRlcyBmb3IgdGhlIHNpbXBs
ZXN0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+cnVsZXM7IHJlcXVpcmlu
ZyB0aGUgcHJveHkgdG8gbG9vayBhdCB0aGUgZW50cmllcyBpbiB0aGUgUm91dGUgaGVhZGVyIGJl
Zm9yZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmRlY2lkaW5nPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+aWYgaXQgY2FuIHVzZSB0aGUgZmlyc3Qg
ZW50cnkgKHNpdHVhdGlvbiBhcmlzaW5nIHRocm91Z2ggY2FzZSAoYikgKSBzZWVtcyBtdWNoPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+bW9yZSBjb21wbGV4PC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+YW5kIHByb25lIHRvIGVycm9yLjwvRk9OVD4N
CjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UaGUgdGV4dCBpbiA2LjM0LjMg
aXMgdW5jbGVhciBhcyB0byB3aGF0IGEgVUEgbXVzdCBkbyBpZiBpdCBpcyB1c2luZyBhbiBvdXRi
b3VuZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnByb3h5OyBJIHRoaW5r
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+aXQgd2lsbCBsZWFkIHRvIHNv
bWUgVUEgZnVuY3Rpb25pbmcgYXMgaW4gY2FzZSAoYSkgYW5kIHNvbWUgYXMgaW4gY2FzZSAoYikg
d2hpY2g8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5pcyB0aGU8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj53b3JzdCBzY2VuYXJpbyBhcyBpdCBiZWNv
bWVzIGFsbW9zdCBpbXBvc3NpYmxlIGZvciBwcm94aWVzIHRvIGtub3cgd2hpY2g8L0ZPTlQ+DQo8
QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5wcm9jZXNzaW5nPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+dG8gYXBwbHkuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPkFsc28sIGNvbnNpZGVyaW5nIHRoZSBhYm92ZSBhbmQgY29udGlu
dWluZyBteSBwcmV2aW91cyBwb2ludCBvbiB0aGlzIHRocmVhZDwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPmFib3V0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJB
cmlhbCI+YSByb2FtaW5nIFVBIHdpc2hpbmcgdG8gcm91dGUgdGhyb3VnaCB0aGUgY29udGV4dCBv
ZiBpdHMgaG9tZSBkb21haW4gcHJveHkgSTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0i
QXJpYWwiPmhhdmUgdGhlIGZvbGxvd2luZyBpbiBtaW5kLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5BIFVBIGF0IHZpc2l0ZWRuZXQuY29tIGhhcyBiZWVuIGdp
dmVuIHByb3h5LnZpc2l0ZWQubmV0IGFzIGl0cyBsb2NhbCBvdXRib3VuZDwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnByb3h5LjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIg
RkFDRT0iQXJpYWwiPlRoZSBVQSB3aXNoZXMgdG8gc2V0IHVwIGEgY2FsbCB0aHJvdWdoIGl0cyBo
b21lIGRvbWFpbiBwcm94eSB0bzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
PmZyaWVuZEBhbm90aGVybmV0LmNvbS48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFy
aWFsIj5UaGUgVUEgbWF5IHdlbGwgY29uc3RydWN0IGEgUm91dGUgaGVhZGVyIHRvIGdldCB0byBw
cm94eS5ob21lbmV0LmNvbSB3aGljaCBsb29rczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPmxpa2U6PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPlJvdXRlICZsdDtzaXA6ZnJpZW5kQGFub3RoZXJuZXQuY29tO21hZGRyPXByb3h5LmhvbWVu
ZXQuY29tJmd0OzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5O
b3csIGEgVUEgdGhhdCBmdW5jdGlvbnMgYXMgaW4gY2FzZSAoYSkgd2lsbCBzZW5kIHRoZSBmb2xs
b3dpbmcgdG88L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5wcm94eS52aXNp
dGVkbmV0LmNvbTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5J
TlZJVEUgc2lwOmZyaWVuZEBhbm90aGVybmV0LmNvbTttYWRkcj1wcm94eS5ob21lbmV0LmNvbTwv
Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5UaGUgUm91dGUgaGVh
ZGVyIHdpbGwgYmUgZW1wdHksIGFzIHRoZSBVQSBoYXMgYWxyZWFkeSBwb3BwZWQgdGhlIGVudHJ5
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+aW50byB0aGUgUi1VUkkuPC9G
T05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlVwb24gcmVjZWl2aW5n
IHRoaXMgcmVxdWVzdCwgcHJveHkudmlzaXRlZG5ldC5jb20gKHdoaWNoIGFzc3VtZXMgYWxsIFVB
IGRvIGNhc2U8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4oYSkgKTwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPndpbGwgc2VlIHRoYXQgdGhlIG1hZGRy
IHJlZmVyZXJlbmNlcyBhIGRvbWFpbiBub3Qgc2VydmVkIGJ5IGl0c2VsZiBhbmQgc288L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5mb3J3YXJkIHRoZTwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnJlcXVlc3QgdG8gcHJveHkuaG9tZW5ldC5jb20sIHdo
aWNoIHdpbGwgc2VlIHRoZSByZXF1ZXN0OjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y
IEZBQ0U9IkFyaWFsIj5JTlZJVEUgc2lwOmZyaWVuZEBhbm90aGVybmV0LmNvbTttYWRkcj1wcm94
eS5ob21lbmV0LmNvbTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFs
Ij53aGljaCBpcyBCaWxseSdzIHZlcnkgZmlyc3QgZXhhbXBsZSBvbiB0aGlzIHRocmVhZC48L0ZP
TlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SW4gdGhpcyBjYXNlIEkg
d291bGQgd2FudCBwcm94eS5ob21lbmV0LmNvbSB0byBub3cgcm91dGUgdXNpbmcgdGhlIFVSSTwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmZyaWVuZEBhbm90aGVybmV0LmNv
bSwgd2hpY2ggd2FzIG15IG9yaWdpbmFsIHBvaW50LjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj5JZiB0aGUgVUEgZnVuY3Rpb25zIGFzIGluIGNhc2UgKGIpIHRo
ZW4gcHJveHkudmlzaXRlZG5ldC5jb20gKHdoaWNoIGFzc3VtZXMgYWxsPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+VUEgZG8gY2FzZSAoYikgKTwvRk9OVD4NCjxCUj48Rk9O
VCBTSVpFPTIgRkFDRT0iQXJpYWwiPnJlY2VpdmVzPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPklOVklURSBzaXA6ZnJpZW5kQGFub3RoZXJuZXQuY29tPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Um91dGU6ICZsdDtzaXA6ZnJpZW5kQGFu
b3RoZXJuZXQuY29tO21hZGRyPXByb3h5LmhvbWVuZXQuY29tJmd0OzwvRk9OVD4NCjwvUD4NCg0K
PFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5wcm94eS52aXNpdGVkbmV0LmNvbSB0aGVuIHBv
cHMgdGhlIGZpcnN0IFJvdXRlIGVudHJ5IGludG8gdGhlIFItVVJJIGFuZCBmb3J3YXJkczwvRk9O
VD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnRvIHByb3h5LmhvbWVuZXQuY29tPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+d2hpY2ggcmVjZWl2ZXMgdGhlIGZv
bGxvd2luZzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JTlZJ
VEUgc2lwOmZyaWVuZEBhbm90aGVybmV0LmNvbTttYWRkcj1wcm94eS5ob21lbmV0LmNvbTwvRk9O
VD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj53aGljaCBpcyBleGFjdGx5
IHRoZSBzYW1lIGFzIGlmIHRoZSBVQS9wcm94eSB3ZXJlIGZ1bmN0aW9uaW5nIGFzIGluIGNhc2Ug
KGEpLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TbywgdG8g
c3VtbWFyaXNlLCBhc3N1bWluZyBVQXMgZnVuY3Rpb24gYXMgaW4gY2FzZSAoYSksIGlmIGEgcHJv
eHkgcmVjZWl2ZXMgYTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlItVVJJ
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+d2l0aCBhbiBtYWRkciB0aGF0
IGRvZXMgbm90IHJlZmVyZW5jZSB0aGUgZG9tYWluIHRoZSBwcm94eSBzZXJ2ZXMgdGhlbiB0aGUg
cHJveHk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5zZW5kcyB0aGUgcmVx
dWVzdCB0byB0aGF0IG1hZGRyLCByZWdhcmRsZXNzIG9mIHRoZSBSb3V0ZSBoZWFkZXJzOyBpZiBh
IHByb3h5PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+cmVjZWl2ZXM8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5hIFItVVJJIHdpdGggYW4gbWFkZHIg
dGhhdCBkb2VzIHJlZmVyZW5jZSB0aGUgZG9tYWluIGl0IHNlcnZlcyB0aGVuIGl0IHN0cmlwczwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnRoZSBtYWRkcjwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmFuZCBnb2VzIHRocm91Z2ggdGhlIG5vcm1hbCBy
b3V0aW5nIHByb2NlZHVyZXMuIFRoZSBvbmx5IHNwZWNpYWwgY2FzZSBwcm9jZXNzaW5nPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+aXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yIEZBQ0U9IkFyaWFsIj50aGUgcmVzdWx0IG9mIGNoZWNraW5nIHRoZSBtYWRkci48L0ZPTlQ+
DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+UmVnYXJkcyw8L0ZPTlQ+DQo8
L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Sy4gUm9iaW5zb24uPC9GT05UPg0K
PC9QPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJS
Pg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0K
PEJSPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkphY2VrX0dyYWJpZWNAM2NvbS5j
b20gb24gMDIvMDEvMjAwMSAxNTowNzoxMzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0i
QXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjwvUD4NCjxCUj4NCg0KPFA+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDtUbzombmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2lwQGxpc3RzLmJlbGwtbGFicy5jb20mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwO2NjOiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBiaWxseUBiaWxseWJpZ2dzLmNvbSwgaGdzQGNzLmNvbHVtYmlh
LmVkdSwgSm9uYXRoYW4gPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJvc2Vu
YmVyZyAmbHQ7amRyb3NlbkBkeW5hbWljc29mdC5jb20mZ3Q7LCZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmZhaXJs
aWVAbnVlcmEuY29tLCBqaG9ybnNieUB1YmlxdWl0eS5uZXQsJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyB2a2dAbHVjZW50LmNvbShiY2M6IEtlaXRoIFJvYmluc29uL01BSU4vTUMx
KSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyA8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDtTdWJq
ZWN0OiBSRTogW1NJUF0gUHJveHkgUm91dGluZyBMb2dpYyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgPC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KPEJS
Pg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkpvbmF0aGFuIFJvc2VuYmVy
ZyB3cm90ZTs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mZ3Q7VG8gY29t
bWVudCBvbiB0aGUgcHJpbWFyeSBpc3N1ZSwgaWdub3JpbmcgdGhlIFJvdXRlIGhlYWRlciBpZiB0
aGUgcmVxdWVzdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZndDtVUkkg
ZG9tYWluIGlzIG5vdCB5b3VyIG93biwgYW5kIHNlbmRpbmcgaXQgdG8gdGhhdCBkb21haW4gZmly
c3QsIGlzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jmd0O2Rhbmdlcm91
cywgSU1ITy4gVGhhdHMgYmVjYXVzZSwgbmVhcmx5IGFzIEkgY2FuIHRlbGwsIGl0IGNvbXBsZXRl
bHkgYnJlYWtzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jmd0O3RoZSBl
eGlzdGluZyB1c2FnZSBvZiByZWNvcmQtcm91dGluZy4gSW4gdGhlIGV4aXN0aW5nIHVzYWdlLCBh
IHByb3h5IGNvcGllczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZndDt0
aGUgcmVxdWVzdCBVUkkgaW4gdGhlIHJlcXVlc3QgaW50byB0aGUgcmVjb3JkLXJvdXRlLCBhbmQg
YWRkcyBpdHMgb3duPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jmd0O21h
ZGRyLiBSZXF1ZXN0cyBpbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24gd2lsbCBvbmx5IGdldCByb3V0
ZWQgY29ycmVjdGx5PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jmd0O3Ro
cm91Z2ggdGhhdCBzYW1lIHNldCBvZiBwcm94aWVzIElGRiBlYWNoIHByb3h5IHVzZXMgdGhlIHRv
cCByb3V0ZSBoZWFkZXIgbm88L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4m
Z3Q7bWF0dGVyIHdoYXQuIElmIHByb3hpZXMgc3RhcnQgdG8gb25seSBzb21ldGltZXMgdXNlIHRo
ZW0sIHdlIHdpbGwgZW5kIHVwPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
Jmd0O3dpdGggaW5jb3JyZWN0bHkgcm91dGVkIHJlcXVlc3RzLjwvRk9OVD4NCjwvUD4NCg0KPFA+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JJ20gbm90IHN1cmUgaWYgJ2lnbm9yaW5nIHRoZSBS
b3V0ZSBoZWFkZXIgaWYgdGhlIHJlcXVlc3Q8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj5VUkkgZG9tYWluIGlzIG5vdCB5b3VyIG93biwgYW5kIHNlbmRpbmcgaXQgdG8gdGhh
dCBkb21haW4gZmlyc3QnIGJyZWFrczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPmFueXRoaW5nLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkkgY2Fu
IHNlZSBpdCBtYXkgYWRkIGFub3RoZXIgcHJveHkgdG8gdGhlIHBhdGgsIGJ1dCBhdCBsZWFzdCBh
bGwgcmVjb3JkLXJvdXRlZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlBy
b3hpZXMgYXJlIG9uIHRoZSBwYXRoIGFzIHdlbGwuIERvaW5nIG90aGVyd2lzZSB3aWxsIGJyZWFr
IHJvdXRpbmcgKEkgZ2F2ZSBhbjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
PmV4YW1wbGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5pbiBvbmUgb2Yg
bXkgcHJldml1b3MgcG9zdGluZ3MpLiBJIHdvdWxkIGFyZ3VlIHRoYXQgcHJveHkgY2Fubm90IGJs
aW5kbHkgZm9sbG93PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+bG9naWMg
J3JlcGxhY2UgUlVSSSB3aXRoIFJvdXRlJyBubyBtYXR0ZXIgd2hhdCBqdXN0IGxpa2UgaXQgZG9l
cyBub3QgcHJveHk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5yZXNwb25z
ZXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5kb3duc3RyZWFtIGlmIHRv
cC12aWEgZG9lc24ndCBtYXRjaCB0aGUgc2VydmVyIC0gaXQgY2hlY2tzIGlmIGl0IG1hdGNoZXMg
Zmlyc3QuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZndDtT
bywgSSB3b3VsZCBtb2RpZnkgbXkgcHJvcG9zYWwgdG8gc2F0aXNmeSBzb21lIG9mIHRoZSBvdGhl
ciByZXF1aXJlbWVudHM6PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJp
YWwiPiZndDsxLiBJZiB0aGVyZSBpcyBhIFJvdXRlIGhlYWRlciBpbiBhIHJlcXVlc3QsIHRoYXQg
QUxXQVlTIHRha2VzIHByaW9yaXR5IGZvcjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0i
QXJpYWwiPiZndDtyb3V0aW5nIHRoZSByZXF1ZXN0LjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIg
RkFDRT0iQXJpYWwiPiZndDsyLiBJZiB0aGVyZSBpcyBub25lLCBhbmQgdGhlIHJlcXVlc3QgVVJJ
IGhhcyBhIGRvbWFpbiBOT1QgbWF0Y2hpbmcgdGhhdCBvZjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTIgRkFDRT0iQXJpYWwiPiZndDt0aGUgc2VydmVyLCBidXQgdGhlIGFkZHJlc3MvZG9tYWluIGlu
IHRoZSBtYWRkciBkb2VzLCB0aGUgc2VydmVyIGZvcndhcmRzIHRvPC9GT05UPg0KPEJSPjxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+Jmd0O3RoZSBkb21haW4gaW4gdGhlIHVzZXJob3N0IHBvcnRp
b24gb2YgdGhlIFItVVJJLiBJZiB0aGUgbmVpdGhlciB0aGUgbWFkZHIgb3I8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mZ3Q7dXNlcmhvc3QgaGF2ZSBhbiBpcGFkZHJlc3Mv
ZG9tYWluIG1hdGNoaW5nIHRoZSBwcm94eSwgdGhlIHByb3h5IHNlbmRzIHRoZTwvRk9OVD4NCjxC
Uj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZndDtyZXF1ZXN0IHRvIHRoZSBhZGRyZXNzIGlu
IHRoZSBtYWRkci4gU3RyaXBwaW5nIG9mIG1hZGRyIGlzIG9wdGlvbmFsLjwvRk9OVD4NCjwvUD4N
Cg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj55b3VyIDIgc3VnZ2VzdGlvbiBpcyByZWFs
bHkgY2xvc2Ugd2hhdCBJIHdvdWxkIGhhdmUgaW4gbWluZC4gVGhlcmUncyBhbHNvPC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+YW5vdGhlcjwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPnNjZW5hcmlvOiB3aGVyZSBQcm94eSByZWNlaXZlcyBhIHJlcXVl
c3Qgd2l0aCBtYWRkciB3aGVyZSBuZWl0aGVyIG1hZGRyIG5vciBob3N0PC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+cG9ydGlvbiBvZiBSVVJJIG1hdGNoZXMgdGhlIHNlcnZl
ci48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+TGV0J3Mgc2F5
IHByb3h5IGF0IHNpcC5jb21wYW55LmNvbSByZWNlaXZlcyBhIHJlcXVlc3RzIGxpa2U6PC9GT05U
Pg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnNpcDphYmNAc29tZW9uZS1l
bHNlLmNvbTttYWRkcj1wcm94eS5jb208L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFy
aWFsIj4uLi4uLi4uPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Um91dGU6
ICZsdDtzaXA6MTIzQHlldC1zb21lb25lLWVsc2UuY29tO21hZGRyPXlldC15ZXQtc29tZW9uZS1l
bHNlLmNvbSZndDs8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
QXMgQmlsbHkgcG9pbnRlZCBvdXQgeW91LCBiZWluZyB0aGUgcHJveHksIGRvbid0IHJlYWxseSB3
YW50IHRvIHBvcCBSb3V0ZSBoZWFkZXI8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFy
aWFsIj4mbmJzcDtibGluZGx5LiBJIHdvdWxkIHJhdGhlcjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTIgRkFDRT0iQXJpYWwiPnByb3Bvc2Ugc29tZXRoaW5nIGFsb25nIHRoZXNlcyBsaW5lcyAtIGl0
IGlzIHJlYWxseSBjbG9zZSB0byB5b3VyIDIgY2FzZSAoaXQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0la
RT0yIEZBQ0U9IkFyaWFsIj5hbHNvIHRha2VzIGNhcmUgb2Ygc2NlbmFyaW8gd2hlcmU8L0ZPTlQ+
DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Qcm94eSBoYXMgaXQncyBvd24gb3V0Ym91
bmQgUHJveHkgd2hpY2ggbWF5IGhhdmUgaXRzIG93biBvdXRib3VuZCBQcm94eSBldGMgLSBpZjwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNwO3lvdSB3ZXJlIHRvIHBv
cCBSb3V0ZSBhdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmV2ZXJ5IGhv
cCB0aGUgbWVzc2FnZSB3b3VsZCBuZXZlciBnZXQgdG8gdGhlIHByb3BlciBQcm94aWVzKTo8L0ZP
TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JbnZlc3RpZ2F0ZSBSVVJJIGZpcnN0
OjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPjEpJm5ic3A7Jm5ic3A7IGlm
IG1hZGRyIGV4aXN0IGFuZCBpdCBkb2Vzbid0IG1hdGNoIHlvdXIgZG9tYWluIHNlbmQgbWVzc2Fn
ZSB0bzo8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgLSBhZGRyZXNzIGluZGljYXRlZCBpbiBtYWRkciBhbmQgc3RyaXAgbWFkZHIu
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IC0gb3IsIGlmIG91dGJvdW5kIFByb3h5IGlzIHVzZWQsIHRvIG91dGJvdW5kIFByb3h5
IGFuZCBwcmVzZXJ2ZSBtYWRkcjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIG9yLCByZXR1cm4gNDg4IGlmIHVud2lsbGluZy91
bmFibGUgdG8gZm9yd2FyZCB0aGUgcmVxdWVzdCAoSSBleHBsYWluZWQgbXk8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDtyZWFzb25pbmcgZm9yIDQ4OCBpbiBwcmV2
aW91cyBwb3N0aW5nKTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPjIpJm5i
c3A7Jm5ic3A7IGlmIG1hZGRyIGV4aXN0IGFuZCBpdCBtYXRjaGVzIHlvdXIgZG9tYWluIHN0cmlw
IG1hZGRyIGFuZCBnbyB0byAzPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
MykmbmJzcDsmbmJzcDsgaWYgaG9zdCBwYXJ0IG9mIFJVUkkgZG9lc24ndCBtYXRjaCB5b3VyIGRv
bWFpbiBzZW5kIG1lc3NhZ2UgdG86PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlh
bCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gYWRkcmVzcyBpbmRpY2F0ZWQgaW4gaG9zdCBw
YXJ0IG9mIFJVUkkgYW5kIHByZXNlcnZlIGV4aXN0aW5nIFJVUkkgYW5kPC9GT05UPg0KPEJSPjxG
T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Um91dGUocyksPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
MiBGQUNFPSJBcmlhbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gb3IsIGlmIG91dGJvdW5k
IFByb3h5IGlzIHVzZWQsIHRvIG91dGJvdW5kIFByb3h5IGFuZCBwcmVzZXJ2ZSBleGlzdGluZzwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPlJVUkkgYW5kIFJvdXRlKHMpLDwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPjQpJm5ic3A7Jm5ic3A7IGlmIGhv
c3QgcGFydCBvZiBSVVJJIGRvZXMgbWF0Y2ggeW91ciBkb21haW4gcG9wIGZpcnN0IFJvdXRlIGhl
YWRlciBhbmQgZ288L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5iYWNrIHRv
IDE8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgKG5vdyB5b3VyIFJVUkkgaXMgd2hhdGV2ZXIgUm91dGUgaGVhZGVyIGNvbnRhaW5l
ZCkuPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+NSkmbmJzcDsmbmJzcDsg
aWYgdGhlcmUncyBubyBSb3V0ZSBoZWFkZXIgZG8gd2hhdGV2ZXIgeW91IHdhbnQgKGdldCBjb250
YWN0IGZyb20geW91cjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBsb2NhdGlvbi9yZWdpc3RyYXIgc2VydmVyIG1vc3QgbGlrZWx5
KSBhbmQgZ28gYmFjayB0byAxIChub3cgUlVSSSBpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIg
RkFDRT0iQXJpYWwiPndoYXRldmVyIHlvdSBnb3Q8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZB
Q0U9IkFyaWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZnJvbSBsb2NhdGlvbi9yZWdpc3Ry
YXIgc2VydmVyKTwvRk9OVD4NCjwvUD4NCjxCUj4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFy
aWFsIj5yZWdhcmRzLCBKYWNlayBHcmFiaWVjPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+c2lwOmphY2VrX2dyYWJpZWNAc2lwLjNjb20uY29tPC9GT05UPg0KPC9QPg0KPEJS
Pg0KPEJSPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+U0lQIG1haWxpbmcgbGlzdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPlNJUEBsaXN0cy5iZWxsLWxhYnMuY29tPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9
MiBGQUNFPSJBcmlhbCI+PEEgSFJFRj0iaHR0cDovL2xpc3RzLmJlbGwtbGFicy5jb20vbWFpbG1h
bi9saXN0aW5mby9zaXAiIFRBUkdFVD0iX2JsYW5rIj5odHRwOi8vbGlzdHMuYmVsbC1sYWJzLmNv
bS9tYWlsbWFuL2xpc3RpbmZvL3NpcDwvQT48L0ZPTlQ+DQo8L1A+DQoNCjxQPg0KPC9QPg0KPC9V
TD48L1VMPg0KPC9CT0RZPg0KPC9IVE1MPg==

--0__=qZ4RBtEIUeSqILvJ1q8hEbd4w2HEiu5q2JS17OuizWlK4jpCdWEJwnO5--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 08:00:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22689
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 08:00:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 03F0C4433B; Thu, 18 Jan 2001 07:01:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pallas.host4u.net (pallas.host4u.net [216.71.64.48])
	by lists.bell-labs.com (Postfix) with ESMTP id CC8F344336
	for <SIP@lists.bell-labs.com>; Thu, 18 Jan 2001 07:00:11 -0500 (EST)
Received: from KAGOOROQ77G3M6 ([212.199.50.10])
	by pallas.host4u.net (8.8.5/8.8.5) with SMTP id GAA19950
	for <SIP@lists.bell-labs.com>; Thu, 18 Jan 2001 06:58:36 -0600
From: "Dan Sahar" <dans@kagoor.com>
To: "'SIP discussion list'" <SIP@lists.bell-labs.com>
Message-ID: <DMEFILDNOHJNADOFDHCCCEGMCCAA.dans@kagoor.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0010_01C08160.6925C3A0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [SIP] SIP Media Session
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 18 Jan 2001 15:07:44 +0200

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C08160.6925C3A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

I've been using an H323 call generator comprised of a signalling and
RTP/RTCP generation modules.

Is it possible to combine the RTP generator with a SIP signalling generator
into a SIP call generator?

In other words, is the RTP media layer identical no matter what the session
initiation protocol is?

Thanx in advance.

Regards,

Dan Sahar
Kagoor Networks Ltd.
E-mail: mailto:dans@kagoor.com
Web: www.kagoor.com
______________________________
"..he not busy being born is busy dying."
~Bob Dylan




------=_NextPart_000_0010_01C08160.6925C3A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV>
<P><FONT size=3D2>I've been using an H323 call generator&nbsp;<SPAN=20
class=3D410180513-18012001>comprised of&nbsp;</SPAN><SPAN=20
class=3D410180513-18012001>a </SPAN>signalling and RTP<SPAN=20
class=3D410180513-18012001>/RTCP</SPAN> generation modules.</FONT></P>
<P><FONT size=3D2>Is it possible to combine the RTP generator with a SIP =

signalling generator&nbsp;<SPAN class=3D410180513-18012001>into</SPAN> a =
SIP call=20
generator?</FONT></P>
<P><FONT size=3D2>In other words, is the RTP media layer identical no =
matter what=20
the session&nbsp;<SPAN class=3D410180513-18012001>initiation protocol=20
</SPAN>is?</FONT></P></DIV>
<P><FONT face=3DArial size=3D2><SPAN class=3D410180513-18012001>Thanx in =

advance.</SPAN></FONT></P>
<P><FONT face=3DArial size=3D2>Regards,</FONT></P>
<P><FONT size=3D2><FONT face=3DArial>Dan =
Sahar<BR></FONT></FONT><STRONG><FONT=20
face=3DArial size=3D2>Kagoor Networks Ltd.<BR></FONT></STRONG><FONT =
face=3DArial=20
size=3D2><SPAN =
class=3D410180513-18012001><STRONG>E</STRONG></SPAN>-mail: </FONT><A=20
href=3D"mailto:E-mail:mailto:dans@kagoor.com"><FONT face=3DArial=20
size=3D2>mailto:dans@kagoor.com</FONT></A><BR><FONT face=3DArial =
size=3D2>Web:=20
</FONT><A href=3D"http://www.kagoor.com/"><FONT color=3D#0000ff =
face=3DArial=20
size=3D2>www.kagoor.com</FONT></A><FONT size=3D2><BR><FONT=20
face=3DArial>______________________________<BR></FONT></FONT><FONT=20
face=3DArial><FONT size=3D1>"..he not busy being born is busy dying." =
<BR>~Bob=20
Dylan<BR><!--  END lyrics  --><!--  spacer  --></FONT></FONT></P>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0010_01C08160.6925C3A0--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 08:13:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22989
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 08:13:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D6C0C4433B; Thu, 18 Jan 2001 07:14:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by lists.bell-labs.com (Postfix) with ESMTP id 7EBE344336
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 07:13:29 -0500 (EST)
Received: from benetnash.fokus.gmd.de (benetnash [193.175.133.195])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id OAA25678
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 14:13:16 +0100 (MET)
Received: (from chr@localhost)
	by benetnash.fokus.gmd.de (8.8.8/8.8.8) id OAA22381
	for sip@lists.bell-labs.com; Thu, 18 Jan 2001 14:13:16 +0100 (MET)
From: Christoph Reichert <reichert@fokus.gmd.de>
To: SIP List <sip@lists.bell-labs.com>
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
Message-ID: <20010118141316.A22375@fokus.gmd.de>
References: <5.0.0.25.2.20010117162639.01b82090@imop.cisco.com> <20010117122634.A5496@fdd.com> <5.0.0.25.2.20010117162639.01b82090@imop.cisco.com> <20010117205839.A1115@div8.net> <5.0.0.25.2.20010117182751.01b90d90@imop.cisco.com> <20010117215411.A1229@div8.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20010117215411.A1229@div8.net>; from billy@billybiggs.com on Wed, Jan 17, 2001 at 09:54:11PM -0500
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 18 Jan 2001 14:13:16 +0100

[...]

>   Wasn't there a BOF regarding ad-hoc/multiparty conferencing using SIP?
> I was waiting for minutes, but never saw any.
> 
>   If you want my opinion, I can give it.  I did do some work researching
> the topic.  We should really setup an egroups list or something to bang
> on it.  There always seems to be interest in the topic...

[...]

I am also very interested in the results of this BOF and/or the egroup list.

chris

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 08:51:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23573
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 08:51:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 383854433B; Thu, 18 Jan 2001 07:52:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb19.rediffmail.com (unknown [203.199.83.143])
	by lists.bell-labs.com (Postfix) with SMTP id 49B7544336
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 07:51:37 -0500 (EST)
Received: (qmail 26024 invoked by uid 510); 18 Jan 2001 13:00:44 -0000
Message-ID: <20010118130044.26023.qmail@mailweb19.rediffmail.com>
Received: from unknown (203.197.193.49) by rediffmail.com via HTTP; 18 Jan 2001 13:00:44 -0000
MIME-Version: 1.0
To: "wvdleij@azisa.co.za" <wvdleij@azisa.co.za>,
        "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
Subject:  Re: [SIP] Terminating pending calls
From: "Deepak  Mohan" <deepakwarrier@rediffmail.com>
Content-ID: <Thu_Jan_18_18_30_44_IST_2001_0@mailweb19.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 18 Jan 2001 13:00:44 -0000
Content-Transfer-Encoding: 7bit

Waiting for the response for the BYE seems to be OK

Or you can hack a solution, by just not seding the ACK. Though this is sure to be frowned upon, and vehmently objected to.

Regards,
Deepak

------------- Original Message --------------
Will van der Leij <wvdleij@azisa.co.za> wrote:
To:sip@lists.bell-labs.com
From:Will van der Leij <wvdleij@azisa.co.za>
Date:Thu, 18 Jan 2001 12:19:08 +0200
Subject: [SIP] Terminating pending calls

Hi,
My apologies if this has been covered somewhere in the archives,
I'm still scanning through them.

I have a question regarding the termination of pending INVITEs
without the possibility of the call being set up.
Consider sending an INVITE which gets a 200 OK response.
The UA decides, fow whatever reason, to drop the call. To do
this, the UA sends a BYE. The INVITE, however, needs to be
ACKed as well. Now if the BYE and ACK follow different routes,
then there is the possibility that the ACK arrives first and 
the call gets set up before the BYE terminates it.

Is there anything wrong with sending the BYE after receiving
the 200 OK for the INVITE and then only ACKing the INVITE after
receiving the 200 OK response to the BYE? The only draw back I 
can see here is that the server might retransmit the response 
before it receives the BYE. Or do we send them together?

I was also wondering why we need to send an ACK if we are going to
send a BYE for the call? Can the BYE, in such a case, not perform
the role of the ACK as far as the server is concerned?

Regards,
Will van der Leij

__________/\/^^^^^^\______
W.R.van der Leij
Azisa (Pty) Ltd.
http://www.azisa.co.za

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 09:10:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24068
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 09:10:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C122F443C8; Thu, 18 Jan 2001 08:11:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb19.rediffmail.com (unknown [203.199.83.143])
	by lists.bell-labs.com (Postfix) with SMTP id 5CB6F443C4
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 08:10:52 -0500 (EST)
Received: (qmail 8811 invoked by uid 510); 18 Jan 2001 13:15:29 -0000
Message-ID: <20010118131529.8810.qmail@mailweb19.rediffmail.com>
Received: from unknown (203.197.193.49) by rediffmail.com via HTTP; 18 Jan 2001 13:15:29 -0000
MIME-Version: 1.0
To: "sipjames@yahoo.com" <sipjames@yahoo.com>,
        "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
Subject:  Re: [SIP] A foolish question on 3xx response.
From: "Deepak  Mohan" <deepakwarrier@rediffmail.com>
Content-ID: <Thu_Jan_18_18_45_29_IST_2001_0@mailweb19.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 18 Jan 2001 13:15:29 -0000
Content-Transfer-Encoding: 7bit

See draft-ietf-sip-call-flows-02.txt section 3.1.6.

Also note that the call-id of the new INVITEs can be different. I believe the CSeq value should help you to disambiguate any late responses of the previous transaction.

-Deepak

------------- Original Message --------------
james jack <sipjames@yahoo.com> wrote:
To:sip@lists.bell-labs.com
From:james jack <sipjames@yahoo.com>
Date:Thu, 18 Jan 2001 02:53:01 -0800 (PST)
Subject: [SIP] A foolish question on 3xx response.

Dear All:
   I have one question to consult, for example,
when a UA receive a 3xx response for INVITE with
multiple Contact headers, it will send 
INVITE requests to new address, then should these
new invite requests with new Call-ID?
   Thanks in advance!
   Best regards! 
                      Yours: James

__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 09:42:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25090
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 09:42:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 56FEA4433B; Thu, 18 Jan 2001 08:43:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb10.rediffmail.com (unknown [203.199.83.26])
	by lists.bell-labs.com (Postfix) with SMTP id 6B51C44336
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 08:42:33 -0500 (EST)
Received: (qmail 1209 invoked by uid 510); 18 Jan 2001 14:35:23 -0000
Message-ID: <20010118143523.1208.qmail@mailweb10.rediffmail.com>
Received: from unknown (203.197.174.43) by rediffmail.com via HTTP; 18 Jan 2001 14:35:23 -0000
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
From: "Vijeth  D" <vijethd@rediffmail.com>
Content-ID: <Thu_Jan_18_20_05_23_IST_2001_0@mailweb10.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Subject: [SIP] Bug in bis-02
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 18 Jan 2001 14:35:23 -0000
Content-Transfer-Encoding: 7bit

Hi,
   The ACK message i.e step 8 should have the request URI same as the sip URL in the Contact header of step 6 and proxy should not remove it..
Has this been discovered earlier or Am i missing something.

_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 09:44:59 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25183
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 09:44:59 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 118E9443CE; Thu, 18 Jan 2001 08:45:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailweb14.rediffmail.com (unknown [203.199.83.22])
	by lists.bell-labs.com (Postfix) with SMTP id 4C865443CD
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 08:44:54 -0500 (EST)
Received: (qmail 13053 invoked by uid 510); 18 Jan 2001 14:32:15 -0000
Message-ID: <20010118143215.13051.qmail@mailweb14.rediffmail.com>
Received: from unknown (203.197.174.43) by rediffmail.com via HTTP; 18 Jan 2001 14:32:15 -0000
MIME-Version: 1.0
To: "sip@lists.bell-labs.com" <sip@lists.bell-labs.com>
From: "Vijeth  D" <vijethd@rediffmail.com>
Content-ID: <Thu_Jan_18_20_02_15_IST_2001_0@mailweb14.rediffmail.com>
Content-type:  text/plain
Content-Description:  Body
Content-Transfer-Encoding:  7bit
Subject: [SIP] SIP Proxy server
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: 18 Jan 2001 14:32:15 -0000
Content-Transfer-Encoding: 7bit

Hi,
 Can the Sip proxy or redirect servers listen to any other port than 5060. If so, how do the SIP entities come to know about it.



_____________________________________________________
Chat with your friends as soon as they come online. Get Rediff Bol at
http://bol.rediff.com





_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 10:00:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25744
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 10:00:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C9B37443CE; Thu, 18 Jan 2001 09:01:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id E53124433B
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 09:00:37 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA13411;
	Thu, 18 Jan 2001 10:03:08 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9K2D9A>; Thu, 18 Jan 2001 09:57:06 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF27F41D@DYN-EXCH-001.dynamicsoft.com>
From: Peter Mataga <PMataga@dynamicsoft.com>
To: "'Rick Dean'" <siplist@fdd.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Back-to-back UAs
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 18 Jan 2001 09:57:06 -0500

> -----Original Message-----
> From: Rick Dean [mailto:siplist@fdd.com]
> Sent: Tuesday, January 16, 2001 12:37 PM
> To: sip@lists.bell-labs.com
> Subject: Re: [SIP] Back-to-back UAs
> 
> 
> 
> Keith,
> 
> I apologize.  Back-to-back UA is another name for Rosenberg's
> 3rd Party Call Control.  3PCC was first published here..
> http://www.cs.columbia.edu/~hgs/sip/drafts/draft-rosenberg-sip-3pcc-00.txt
> The draft does not use the B2BUA moniker.

Perhaps because 3pcc is not exactly the same as B2BUA, at least as used in
this thread and elsewhere. I would certainly agree that "back-to-back" UAs
*sound* like they ought to be in 3pcc mode, in the sense that both UAs are
initiating INVITE transactions in 3pcc (and thus "facing outward" :-).

However, the B2BUA moniker is being used for (or at least to include) modes
where the UAs are, well, "front-to-back"? "back-to-front"? Hmm, I guess we
can see why neither of these was used ... [Note that the 3pcc draft uses (in
a footnote) the term "virtual UAS/UAC" for the case where the entity
providing mid-call control did not initiate one of the original calls, as is
the case for most of the device control scenarios that Bill Marshall
mentions in his post to this thread.] 

The characterization of a proxy as a B2BUA with constrained behavior as in
Bill's post seems like the right idea to me. 3pcc is a specific kind of
constrained B2BUA also, but it's not the general case.

> 
> Yes, 3PCC/B2BUA can break the end to end nature.  Sometimes this
> is desired.  A company may wish to hide its internal
> routing.  A fragile gateway may need a SIP wrapper/firewall.  etc.
> 
> The biggest problem I currently experience is 
> looping.  I wish all B2BUAs would preserve 
> the call-id.  Unfortunately, I can't get rid of my biggest
> B2BUA, the public switched telephony network (PSTN).  :-/
> 
> --
> Rick
> rick_dean@3com.com
> 
> On Tue, Jan 16, 2001 at 12:57:05PM -0000, Drage, Keith (Keith) wrote:
> > I keep seeing mention of back-to-back UAs and I think I 
> understand what is
> > trying to be done with them. 
> > 
> > I do however see an issue that there is apparently no 
> documentation of this
> > concept in any draft. Therefore it leads to the question of 
> when does a
> > proxy become a back-to-back UA, and therefore perform all 
> error handling and
> > syntactic checking as a UA rather than a proxy. Because 
> there is no mention
> > in any draft, it would probably never be identified in any 
> conformance
> > statement, and an attaching UA to this concept might 
> therefore see behaviour
> > that was not expected.
> > 
> > I also see problems where, because it is not documented, 
> the impact of
> > interactions with other drafts may not have been assessed. 
> For example, is
> > there an impact on the privacy draft, such that the 
> identifiers passed using
> > the concepts of the privacy draft will never pass the 
> back-to-back UA? Do we
> > have problems with any headers that have been ciphered, 
> because we do not
> > wish to release them outside proxies?
> > 
> > I would therefore ask, if such a concept is meant to 
> legally exist, should
> > be not at least define it somewhere. (Thats assuming I 
> haven't missed it
> > somewhere!)
> > 
> > Keith Drage
> > Keith Drage
> > Lucent Technologies
> > Tel: +44 1793 776249
> > Email: drage@lucent.com
> > 
> > _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> "This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip
> to subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body"
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 10:59:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27301
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 10:59:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 78CED4433B; Thu, 18 Jan 2001 10:00:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail15a.boca15-verio.com (unknown [208.55.91.57])
	by lists.bell-labs.com (Postfix) with SMTP id EF3A244336
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 09:59:21 -0500 (EST)
Received: from www.snowshore.com (128.241.144.247)
	by mail15a.boca15-verio.com (RS ver 1.0.58s) with SMTP id 1110099329
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 10:58:51 -0500 (EST)
From: "Eric Burger" <eburger@snowshore.com>
To: "SIP List" <sip@lists.bell-labs.com>
Subject: RE: [SIP] Early media replacement.
Message-ID: <NEBBLACLCLHMJBCAJGOEKEOACIAA.eburger@snowshore.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <E79883AEA37FD411A58C00508BAC5F4B2B5C7D@exchange1.nuera.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Loop-Detect: 1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 18 Jan 2001 10:59:15 -0500
Content-Transfer-Encoding: 7bit

RE: [SIP] Early media replacement.The confusing part is the text part of 183
:-)

"The 183 (Session Progress) response is used to convey information about the
progress of the call which is not otherwise classified" implies the gateway
does know what is going on.

What started the whole thread was the problem of interpreting non-digital
call progress, such as 1A or PBX-generated call progress tones. The problem
with the original PSTN solution is the well documented problem of toll
fraud.  In the PSTN, most carriers address this possibility by either
establishing a one-way voice path and dropping the call in 30 to 48 seconds
if answer supervision is not applied, or starting billing irrespective of
answer supervision after 48 to 60 seconds.

I can't speak for the list, but my concern is that we're opening the same
hole in the packet network that exists in the PSTN.  Moreover, we have the
technology to eliminate most of the cases where the PSTN needed to open that
hole.  I think that's why there's such pushback to the whole idea.

Because I don't personally know of any gateways that can do CPA *today*, I'd
begrudgingly agree to "183 Status Unknown".  If the "we can't change
anything even if it's wrong or confusing police" don't like it, keep the
"Session Progress" token.  I would expect a paragraph in Section 13 (bis) on
the theft of service issue, and would hope to see text similar to Robert's
below explaining what 183 is for in the annotated version / implementer's
guide.


  -----Original Message----
  From: sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Fairlie-Cuninghame,
Robert
  Sent: Wednesday, January 17, 2001 5:38 PM
  To: 'Eric Burger'; sip@lists.bell-labs.com
  Subject: RE: [SIP] Early media replacement.


  Eric,

  If a gateway, knows what's going on then it should send the appropriate
response code (ie, 180, 182, etc with SDP). If the gateway _doesn't_ know
what is going on then it can only send the 183 Session Progress response.
It's not really helpful if the gateway knows what is happening but sends a
response that doesn't convey any information (ie, 183 with SDP)! We don't
need another "I don't know what's going on" Response Code. ("184 Session
Confused"??<grin>)

  Robert.

  -- My opinions are my own and should not be taken as representing those of
Nuera Communications, Inc. --



      -----Original Message-----
      From:   Eric Burger [mailto:eburger@snowshore.com]
      Sent:   Thursday, January 18, 2001 9:07 AM
      To:     sip@lists.bell-labs.com
      Subject:        RE: [SIP] Early media replacement.

      Why no middle ground:

      200 OK :  The call is established, everyone's happy
      183 :     Something's going on that I understand; here it is...
      184 :     Something's going on that I don't understand; here's the
audio

      This gets around just about all of the issues raised:

      1. Either a call is established (200) or it's in the process of being
      established (18x).  Established calls have the audio path established.
      Calls not established (181, 182, 183, et. al.) don't have the audio
path
      established, except for the case of 184.

      2. If there's a billing policy that needs to police media cut-through,
it
      can trigger off the 184 message.

      3. It's forward compatible: as we get a truly digital GSTN, the
dependence
      on audio cut-through for human call progress analysis will go away.
By not
      overloading 183, we make life much easier.

      > ----- Forwarded message from Rick Dean <siplist@fdd.com> -----
      > Date: Tue, 16 Jan 2001 10:58:05 -0600
      > From: Rick Dean <siplist@fdd.com>
      > In-Reply-To:
      > <B65B4F8437968F488A01A940B21982BF9AB0D8@DYN-EXCH-001.dynamicsoft.c
      > om>; from jdrosen@dynamicsoft.com on Tue, Jan 16, 2001 at
01:34:26AM -0500
      >
      > On Tue, Jan 16, 2001 at 01:34:26AM -0500, Jonathan Rosenberg wrote:
      > > > -----Original Message-----
      > > > From: Rick Dean [mailto:siplist@fdd.com]
      > > >
      > > > On Tue, Jan 09, 2001 at 01:25:41AM -0500, Jonathan Rosenberg
wrote:
      [snip]
      > > > PSTN interoperability is paramount to me.
      > > > Unfortunately, my calls need to work better
      > > > than 99% of the time.
      [snip]
      > Sure, if a gateway knows the far end is busy, it should send
      > a 486 busy -- no debate.  If the gateway has unknown progress media
      > which might be busy-tone, ringback, or voice prompting; sending 200
      > OK helps manage the audio channel.   Do you expect the human to
      > hit a key on busy tone so his UA sends a CANCEL?  or should
      > he just know to wait?
      >
      > I regret the 200 OK notion.  With audio, I argue a session
      > is established.  As a call originating UA, how to I suspend or
      > redirect the early media if my INVITE won't complete?
      >
      > Sorry to be such as pain on this subject.
      [snip]
      > > >  Hopefully, the gateway builders will
      > > > do the right thing.
      > >
      > > Its not a question of lazy implementations. Its a question of not
having
      > > enough
      > > information to send anything but early media.



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 15:51:07 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05146
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 15:51:06 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0864144338; Thu, 18 Jan 2001 14:51:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id 0559044336
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 14:50:36 -0500 (EST)
Received: from cowboys (IDENT:root@localhost [127.0.0.1])
	by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id OAA23317;
	Thu, 18 Jan 2001 14:49:52 -0600
Message-ID: <010b01c0818f$cf76cdf0$ea036e3f@dynamicsoft.com>
From: "Dean Willis" <dean.willis@softarmor.com>
To: "IETF SIP (E-mail)" <sip@lists.bell-labs.com>
Cc: "Brian Rosen (E-mail)" <Brian.Rosen@marconi.com>,
        "Joerg Ott (E-mail)" <jo@tzi.uni-bremen.de>,
        "Scott Bradner (E-mail)" <sob@harvard.edu>,
        "Allison Mankin (E-mail)" <mankin@isi.edu>
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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [SIP] New Last call for draft-ietf-sip-srv-01, end 25Jan01
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 18 Jan 2001 14:47:01 -0600
Content-Transfer-Encoding: 7bit

I'd like to announce a new WG last call for the SIP SRV draft, retrievable
from:

http://www.ietf.org/internet-drafts/draft-ietf-sip-srv-01.txt

This document was recently updated to reflect changes requested during IESG
review.  From the IESG writeup:

 The IESG requested a split of SIP-SRV from SIP-DHCP, because SIP-SRV
 has applicability beyond the use by SIP-DHCP, and for the SRV procedures
 and usage to be brought in line with RFC 2782.

This last call will close January 25, 2001. Please bring any issues to the
list before then.

Thanks all,

--
Dean Willis
SIP WG cochair


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 17:17:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06240
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 17:17:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7A2E044337; Thu, 18 Jan 2001 16:18:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id 71BF744336
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 16:17:27 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09299;
	Thu, 18 Jan 2001 14:17:10 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA28702;
	Thu, 18 Jan 2001 14:17:08 -0800 (PST)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with ESMTP id KAA20423;
	Thu, 18 Jan 2001 10:11:02 -0800 (PST)
From: Pat Calhoun <Pat.Calhoun@Eng.Sun.COM>
Message-Id: <200101181811.KAA20423@nasnfs.eng.sun.com>
To: "Rohan Mahy" <rohan@cisco.com>, "Rick Dean" <siplist@fdd.com>
Cc: <sip@lists.bell-labs.com>
Reply-To: <Pat.Calhoun@Eng.Sun.COM>
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 18 Jan 2001 10:09:18 -0800
Content-Transfer-Encoding: 7bit

I know that this may sound academic, but I really do object to the use
of the term handoff. In the wireless world, both data and traditional
voice circuit switched, handoffs really means something completely different
from the intent of this draft.

Is there anyway that I can convince the WG to agree to changin the
document name to something more appropriate?

Thanks,

PatC


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 18 17:20:58 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06278
	for <sip-archive@odin.ietf.org>; Thu, 18 Jan 2001 17:20:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 04A6A443D6; Thu, 18 Jan 2001 16:21:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 8AE8E44336
	for <sip@lists.bell-labs.com>; Thu, 18 Jan 2001 16:20:41 -0500 (EST)
Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257)
 id <0G7D00B01Q19V8@firewall.mcit.com> for sip@lists.bell-labs.com; Thu,
 18 Jan 2001 22:19:57 +0000 (GMT)
Received: from dgismtp04.wcomnet.com ([166.38.58.144])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0G7D0078VQ19IT@firewall.mcit.com> for sip@lists.bell-labs.com;
 Thu, 18 Jan 2001 22:19:57 +0000 (GMT)
Received: from CONVERSION-DAEMON by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262)
 id <0G7D00D01Q11UX@dgismtp04.wcomnet.com> for sip@lists.bell-labs.com; Thu,
 18 Jan 2001 22:19:56 +0000 (GMT)
Received: from dgismtp04.wcomnet.com by dgismtp04.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0G7D00D01PZUI2@dgismtp04.wcomnet.com> for
 sip@lists.bell-labs.com; Thu, 18 Jan 2001 22:19:43 +0000 (GMT)
Received: from omzexch007.mcit.com ([166.37.194.38])
 by dgismtp04.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0G7D00D1TPZM5Y@dgismtp04.wcomnet.com> for
 sip@lists.bell-labs.com; Thu, 18 Jan 2001 22:18:58 +0000 (GMT)
Received: by omzexch007 with Internet Mail Service (5.5.2651.58)
 id <CSGVGWCP>; Thu, 18 Jan 2001 22:18:58 +0000
Content-return: allowed
From: "Ngo, Dai" <c-Dai.Ngo@WCOM.Com>
Subject: RE: [SIP] Event Header Token for Presence and InstanT Message
To: sip@lists.bell-labs.com
Message-id: <492EB4A3F68CD411ABE800508B69362E11C499@RIPEXCH002.wcomnet.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-type: multipart/alternative;
 boundary="Boundary_(ID_aUIwg7FX4cdU+md/6bykAw)"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 18 Jan 2001 22:18:56 +0000

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.

--Boundary_(ID_aUIwg7FX4cdU+md/6bykAw)
Content-type: text/plain; charset=ISO-8859-1

Hi all,
 
Could someone help me with this question please. 
Thanks,
 
Dai Ngo

-----Original Message-----
From: Ngo, Dai 
Sent: Tuesday, January 16, 2001 11:27 AM
To: sip@lists.bell-labs.com
Subject: [SIP] Event Header Token for Presence and InstanT Message



Hi all, 

On page 9 of Draft-Roach-Sip-Subscribe-Notify-02.txt stated that "The Event
header is considered mandatory...However, to maintain compatibility with
PINT servers may interpret a SUBSCRIBE request with no "Event" header as
requesting a subscription to PINT events. If the servers do not support
PINT, they should instead return "400 Bad Request"".

Currently the Event header is not mentioned in the Presence/Instant Message
drafts. How do we support Presence and Instant Message then?

Thanks, 

Dai Ngo 


--Boundary_(ID_aUIwg7FX4cdU+md/6bykAw)
Content-type: text/html; charset=ISO-8859-1

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<TITLE>Event Header Token for Presence and InstanT Message</TITLE>

<META content="MSHTML 5.00.3013.2600" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=953281722-18012001>Hi 
all,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=953281722-18012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=953281722-18012001>Could 
someone help me with this question please. </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=953281722-18012001>Thanks,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=953281722-18012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=953281722-18012001>Dai 
Ngo</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader><FONT face="Times New Roman" 
  size=2>-----Original Message-----<BR><B>From:</B> Ngo, Dai <BR><B>Sent:</B> 
  Tuesday, January 16, 2001 11:27 AM<BR><B>To:</B> 
  sip@lists.bell-labs.com<BR><B>Subject:</B> [SIP] Event Header Token for 
  Presence and InstanT Message<BR><BR></DIV></FONT>
  <P><FONT face=Arial size=2>Hi all,</FONT> </P>
  <P><FONT face=Arial size=2>On page 9 of 
  Draft-Roach-Sip-Subscribe-Notify-02.txt stated that "The Event header is 
  considered mandatory...However, to maintain compatibility with PINT servers 
  may interpret a SUBSCRIBE request with no "Event" header as requesting a 
  subscription to PINT events. If the servers do not support PINT, they should 
  instead return "400 Bad Request"".</FONT></P>
  <P><FONT face=Arial size=2>Currently the Event header is not mentioned in the 
  Presence/Instant Message drafts. How do we support Presence and Instant 
  Message then?</FONT></P>
  <P><FONT face=Arial size=2>Thanks,</FONT> </P>
  <P><FONT face=Arial size=2>Dai Ngo</FONT> </P></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_aUIwg7FX4cdU+md/6bykAw)--

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 19 05:43:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26953
	for <sip-archive@odin.ietf.org>; Fri, 19 Jan 2001 05:43:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AD2AF4433B; Fri, 19 Jan 2001 04:44:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp1.gtsgroup.com (smtp1.gtsgroup.com [195.158.230.16])
	by lists.bell-labs.com (Postfix) with SMTP id 98B2444336
	for <sip@lists.bell-labs.com>; Fri, 19 Jan 2001 04:43:27 -0500 (EST)
Received: by brubhdpnt01.gtsgroup.com with Internet Mail Service (5.5.2650.21)
	id <DDVGA60S>; Fri, 19 Jan 2001 11:42:56 +0100
Message-ID: <D52BF6463BA3D311BFA700508B63C5AA034A8057@brumsgpnt01.gtsgroup.com>
From: "Agboh, Charles" <charles.agboh@ebone.com>
To: "'sip-h323@egroups.com'" <sip-h323@egroups.com>
Cc: ITU-SG16@mailbag.cps.intel.com,
        "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C08204.93CB2CE0"
Subject: [SIP] SIP support by H.323 gateways
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 19 Jan 2001 11:42:53 +0100

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_01C08204.93CB2CE0
Content-Type: text/plain;
	charset="iso-8859-1"

 <<Advertisement of SIP Support by H.323 Gateways.doc>>  <<Advertisement of
SIP by H323GW.txt>> 


Hello experts;

Please read the attached document and if possible, could you please try to
answer the following question;

Are there any capabilities that you might want to advertise that might be
important when
an H.323 gatekeeper selects a H.323-SIP Gateway?

Best Regards,
Charles
------------8-)--------------------------------------
Charles Agboh - IP Telephony Systems Engineer
ebOne
IP Engineering
RFC822: charles.agboh@ebone.com
Tel:  +32 (0) 2 658 4243
mob: +32 495 58 52 67
Fax: +32(0) 2 658 5118
http://www.ebone.com

Quan Yin Method


------_=_NextPart_000_01C08204.93CB2CE0
Content-Type: application/msword;
	name="Advertisement of SIP Support by H.323 Gateways.doc"
Content-Disposition: attachment;
	filename="Advertisement of SIP Support by H.323 Gateways.doc"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAJQAAAAAAAAAA
EAAAJwAAAAEAAAD+////AAAAACQAAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAcQAJBAAAABK/AAAAAAAAEAAAAAAABAAAbAwAAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAA
AAAJBBYAHhYAABZBAQAWQQEAbAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAAYBAAAAAAAABgEAAAYB
AAAAAAAABgEAAAAAAAAGAQAAAAAAAAYBAAAAAAAABgEAABQAAAAAAAAAAAAAABoBAAAAAAAAGgEA
AAAAAAAaAQAAAAAAABoBAAAAAAAAGgEAAAwAAAAmAQAAFAAAABoBAAAAAAAA0QkAALYAAABGAQAA
AAAAAEYBAAAAAAAARgEAAAAAAABGAQAAAAAAAEYBAAAAAAAARgEAAAAAAABGAQAAAAAAAEYBAAAA
AAAAlgkAAAIAAACYCQAAAAAAAJgJAAAAAAAAmAkAAAAAAACYCQAAAAAAAJgJAAAAAAAAmAkAACQA
AACHCgAA9AEAAHsMAACEAAAAvAkAABUAAAAAAAAAAAAAAAAAAAAAAAAABgEAAAAAAABGAQAAAAAA
AAAAAAAAAAAAAAAAAAAAAABGAQAAAAAAAEYBAAAAAAAARgEAAAAAAABGAQAAAAAAALwJAAAAAAAA
cgQAAAAAAAAGAQAAAAAAAAYBAAAAAAAARgEAAAAAAAAAAAAAAAAAAEYBAAAAAAAARgEAAAAAAABy
BAAAAAAAAHIEAAAAAAAAcgQAAAAAAABGAQAAlgEAAAYBAAAAAAAARgEAAAAAAAAGAQAAAAAAAEYB
AAAAAAAAlgkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgEAAAAAAAAaAQAAAAAAAAYBAAAAAAAABgEA
AAAAAAAGAQAAAAAAAAYBAAAAAAAARgEAAAAAAACWCQAAAAAAAHIEAAAkBQAAcgQAAAAAAAAAAAAA
AAAAAJYJAAAAAAAABgEAAAAAAAAGAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlgkAAAAAAABGAQAAAAAAADoBAAAMAAAAwAMtcfWB
wAEaAQAAAAAAABoBAAAAAAAA3AIAAJYBAACWCQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQWR2
ZXJ0aXNlbWVudCBvZiBTSVAgU3VwcG9ydCBieSBILjMyMyBHYXRld2F5cw0NQXMgdGhlIFNlc3Np
b24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBnYWlucyB3aWRlciBhY2NlcHRhbmNlLCBpdCBp
cyBpbXBvcnRhbnQgdG8gYnVpbGQgZ2F0ZXdheXMgdGhhdCBwcm92aWRlIGFuIGludGVyd29ya2lu
ZyBmdW5jdGlvbiBiZXR3ZWVuIHRoZSB0d28gcHJvdG9jb2xzLiBJdCBpcyBvdXIgcmVjb21tZW5k
YXRpb24gdGhhdCB3ZSBhZGQgU0lQIHRvIHRoZSBsaXN0IG9mIHN1cHBvcnRlZCBwcm90b2NvbHMg
YWR2ZXJ0aXNlZCBieSBhbiBILjMyMyBnYXRld2F5IHRvIGl0cyBnYXRla2VlcGVyLiINDVRoZSBz
ZW1hbnRpY3Mgb2YgZXhpc3RpbmcgZGVzaXJlZC9zdXBwb3J0ZWQgcHJvdG9jb2wgaW5mb3JtYXRp
b24gZWxlbWVudHMgd2VyZSBub3QgYXBwcm9wcmlhdGUgZm9yIGFuIEguMzIzIGdhdGV3YXkgdG8g
aW5kaWNhdGUgU0lQIHN1cHBvcnQgdG8gYW4gSC4zMjMgZ2F0ZWtlZXBlci4gIEN1cnJlbnRseSwg
dGhlIGJlc3QgcHJhY3RpY2UgZm9yIGEgSC4zMjMgZ2F0ZXdheSAoc3VwcG9ydGluZyBTSVApIGlt
cGxlbWVudGF0aW9uIGlzIHRvIHVzZSB0aGUgaDMyMyBpbmZvcm1hdGlvbiBlbGVtZW50IGluIHRo
ZSBTdXBwb3J0ZWRQcm90b2NvbHMgY2hvaWNlIGZvciB0aGlzIHB1cnBvc2UuICBUaGUgdXNlIG9m
IHN1Y2ggYSBmaWVsZCBtZWFucyB0aGF0IHRoaXMgSC4zMjMgZ2F0ZXdheSAoc3VwcG9ydGluZyBT
SVApIGlzIGEgcHVyZSBILjMyMyBwcm94eSwgd2hpY2ggaXMgbm90IHNlbWFudGljYWxseSBjb3Jy
ZWN0LiAgDQ1TdXBwb3J0ZWRQcm90b2NvbHMgOjo9IENIT0lDRSB7DSAgICBub25TdGFuZGFyZERh
dGEgTm9uU3RhbmRhcmRQYXJhbWV0ZXIsDSAgICBoMzEwIEgzMTBDYXBzLA0gICAgaDMyMCBIMzIw
Q2FwcywNICAgIGgzMjEgSDMyMUNhcHMsDSAgICBoMzIyIEgzMjJDYXBzLA0gICAgaDMyMyBIMzIz
Q2FwcywNICAgIGgzMjQgSDMyNENhcHMsDSAgICB2b2ljZSBWb2ljZUNhcHMsDSAgICB0MTIwLW9u
bHkgVDEyME9ubHlDYXBzLA0gICAgLi4uLA0gICAgbm9uU3RhbmRhcmRQcm90b2NvbCBOb25TdGFu
ZGFyZFByb3RvY29sLA0gICAgdDM4RmF4QW5uZXhiT25seSBUMzhGYXhBbm5leGJPbmx5Q2FwcywN
ICAgIHNpcCBTSVBDYXBzDSB9DQ1TSVBDYXBzIDo6PSBTRVFVRU5DRQ17DSAgICBub25TdGFuZGFy
ZERhdGEgTm9uU3RhbmRhcmRQYXJhbWV0ZXIgT1BUSU9OQUwsDSAgICBkYXRhUmF0ZXNTdXBwb3J0
ZWQgU0VRVUVOQ0UgT0YgRGF0YVJhdGUgT1BUSU9OQUwsDSAgICBzdXBwb3J0ZWRQcmVmaXhlcyBT
RVFVRU5DRSBPRiBTdXBwb3J0ZWRQcmVmaXgsDSAgICAuLi4NfQ0NQ2FsbENhcGFjaXR5SW5mbyA6
Oj0gU0VRVUVOQ0Ugew0gICAgdm9pY2VHd0NhbGxzQXZhaWxhYmxlIFNFUVVFTkNFIE9GIENhbGxz
QXZhaWxhYmxlIE9QVElPTkFMLA0gICAgaDMxMEd3Q2FsbHNBdmFpbGFibGUgU0VRVUVOQ0UgT0Yg
Q2FsbHNBdmFpbGFibGUgT1BUSU9OQUwsDSAgICBoMzIwR3dDYWxsc0F2YWlsYWJsZSBTRVFVRU5D
RSBPRiBDYWxsc0F2YWlsYWJsZSBPUFRJT05BTCwNICAgIGgzMjFHd0NhbGxzQXZhaWxhYmxlIFNF
UVVFTkNFIE9GIENhbGxzQXZhaWxhYmxlIE9QVElPTkFMLA0gICAgaDMyMkd3Q2FsbHNBdmFpbGFi
bGUgU0VRVUVOQ0UgT0YgQ2FsbHNBdmFpbGFibGUgT1BUSU9OQUwsDSAgICBoMzIzR3dDYWxsc0F2
YWlsYWJsZSBTRVFVRU5DRSBPRiBDYWxsc0F2YWlsYWJsZSBPUFRJT05BTCwNICAgIGgzMjRHd0Nh
bGxzQXZhaWxhYmxlIFNFUVVFTkNFIE9GIENhbGxzQXZhaWxhYmxlIE9QVElPTkFMLA0gICAgdDEy
ME9ubHlHd0NhbGxzQXZhaWxhYmxlIFNFUVVFTkNFIE9GIENhbGxzQXZhaWxhYmxlIE9QVElPTkFM
LA0gICAgdDM4RmF4QW5uZXhiT25seUd3Q2FsbHNBdmFpbGFibGUgU0VRVUVOQ0UgT0YgQ2FsbHNB
dmFpbGFibGUgT1BUSU9OQUwsDSAgICB0ZXJtaW5hbENhbGxzQXZhaWxhYmxlIFNFUVVFTkNFIE9G
IENhbGxzQXZhaWxhYmxlIE9QVElPTkFMLA0gICAgbWN1Q2FsbHNBdmFpbGFibGUgU0VRVUVOQ0Ug
T0YgQ2FsbHNBdmFpbGFibGUgT1BUSU9OQUwsDSAgICAuLi4sDSAgICBzaXBHd0NhbGxzQXZhaWxh
YmxlIFNFUVVFTkNFIE9GIENhbGxzQXZhaWxhYmxlIE9QVElPTkFMDSB9DQ0AAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAvBAAA
MAQAAFMFAAApBwAAdwgAAIcIAACLCAAASAkAACwMAABoDAAAawwAAGwMAAD7APsA+/X79fv1+wAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKQioCaAgAbkgJBAAHaAgAbkgJBAAMAAQAAC8EAAAw
BAAAUwUAAFQFAAAoBwAAKQcAAEkHAABzBwAAhgcAAJkHAACsBwAAvwcAANIHAADlBwAA+gcAABYI
AAAfCAAATAgAAHcIAACHCAAAiggAAIsIAACgCAAAoggAANUIAAALCQAAPgkAAEYJAAD9AAAAAAAA
AAAAAAAA+wAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAA
APsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAA
AAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAA
AAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7
AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAA
AAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAA
AAD7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEPAAMAAAMkAwABAAAAAQEAABwABAAALwQAADAE
AABTBQAAVAUAACgHAAApBwAASQcAAHMHAACGBwAAmQcAAKwHAAC/BwAA0gcAAOUHAAD6BwAAFggA
AB8IAABMCAAAdwgAAIcIAACKCAAAiwgAAKAIAACiCAAA1QgAAAsJAAA+CQAARgkAAEgJAABJCQAA
aQkAAKgJAADmCQAAJAoAAGIKAACgCgAA3goAABwLAABeCwAAqAsAAOgLAAAjDAAALAwAAGgMAABr
DAAAbAwAAPwAAAD6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMCDwAFAgEABQAALkYJAABICQAASQkA
AGkJAACoCQAA5gkAACQKAABiCgAAoAoAAN4KAAAcCwAAXgsAAKgLAADoCwAAIwwAACwMAABoDAAA
awwAAGwMAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA
AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAASHAAfsNAvILDgPSGw
CAcisAgHI5CgBSSQoAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASABAACgABAFsADwAC
AAAAAAAAACQAAEDx/wIAJAAAAAYATgBvAHIAbQBhAGwAAAACAAAABABtSAkESAABQAEAAgBIAAAA
CQBIAGUAYQBkAGkAbgBnACAAMQAAABAAAQAGJAETpPAAFKQ8AEAmABMANQiBQ0ocAEtIHABPSgIA
UUoCAAAAAAAAAAAAAAAAAAAAAAAAPABBQPL/oQA8AAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIA
YQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAACoAQkABAPIAKgAAAAkAQgBvAGQAeQAg
AFQAZQB4AHQAAAAFAA8AAyQDAAAAAAAAAGwIAAAGAAAWAAAFAP////8ABAAAbAwAAAcAAAAABAAA
RgkAAGwMAAAIAAAACgAAAAAEAABsDAAACQAAAAAAAACjAAAArwAAAHgCAACKAgAAKQMAADsDAABN
AwAAXAMAAF0DAABxAwAA7wMAAPgDAAAjBAAANgQAADcEAABKBAAAfwQAAIYEAACLBAAAkgQAAKYE
AAC1BAAAtgQAAMoEAADZBAAA6wQAAPgEAAAABQAADwUAACAFAAAtBQAAPAUAAEkFAABZBQAAbQUA
AIIFAACPBQAAnQUAAM0FAADbBQAACwYAABkGAABJBgAAVwYAAIcGAACVBgAAxQYAANMGAAADBwAA
EQcAAEUHAABTBwAAjwcAAJ0HAACsBwAAwgcAAM8HAADdBwAA7AcAAP0HAAAKCAAAGAgAADAIAABD
CAAAUAgAAF4IAABuCAAABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc
AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAAAAAAIgIAADUCAAApAwAAPQMAAE0D
AABcAwAAdwMAAHsDAACKAwAAjgMAAJ0DAAChAwAAsAMAALQDAADDAwAAxwMAANYDAADaAwAA6QMA
AO4DAAD+AwAABwQAABoEAAAeBAAAIwQAADYEAABQBAAAYAQAAHsEAAB+BAAAiwQAAJQEAACmBAAA
tQQAANkEAADrBAAADwUAACAFAABJBQAAWwUAAG0FAACCBQAArAUAAMAFAADqBQAA/gUAACgGAAA8
BgAAZgYAAHoGAACkBgAAuAYAAOIGAAD2BgAAIAcAADgHAABiBwAAggcAAKwHAADCBwAA7AcAAP0H
AAAnCAAAKwgAADAIAABDCAAAbggAAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa
AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoA
BwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcA//8UAAAABgBDAEEARwBC
AE8ASAAtAEMAOgBcAFYAbwBJAFAAXABBAGQAdgBlAHIAdABpAHMAZQBtAGUAbgB0ACAAbwBmACAA
UwBJAFAAIABTAHUAcABwAG8AcgB0ACAAYgB5ACAASAAuAGQAbwBjAAYAQwBBAEcAQgBPAEgAOgBD
ADoAXABWAG8ASQBQAFwAQQBkAHYAZQByAHQAaQBzAGUAbQBlAG4AdAAgAG8AZgAgAFMASQBQACAA
UwB1AHAAcABvAHIAdAAgAGIAeQAgAEgALgAzADIAMwAgAEcAYQB0AGUAdwBhAHkAcwAuAGQAbwBj
AAYAQwBBAEcAQgBPAEgAQgBDADoAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkA
IABzAGEAdgBlACAAbwBmACAAQQBkAHYAZQByAHQAaQBzAGUAbQBlAG4AdAAgAG8AZgAgAFMASQBQ
ACAAUwB1AHAAcABvAHIAdAAgAGIAeQAgAEgALgBhAHMAZAAGAEMAQQBHAEIATwBIADoAQwA6AFwA
VgBvAEkAUABcAEEAZAB2AGUAcgB0AGkAcwBlAG0AZQBuAHQAIABvAGYAIABTAEkAUAAgAFMAdQBw
AHAAbwByAHQAIABiAHkAIABIAC4AMwAyADMAIABHAGEAdABlAHcAYQB5AHMALgBkAG8AYwAGAEMA
QQBHAEIATwBIADoAQwA6AFwAVgBvAEkAUABcAEEAZAB2AGUAcgB0AGkAcwBlAG0AZQBuAHQAIABv
AGYAIABTAEkAUAAgAFMAdQBwAHAAbwByAHQAIABiAHkAIABIAC4AMwAyADMAIABHAGEAdABlAHcA
YQB5AHMALgBkAG8AYwAGAEMAQQBHAEIATwBIADoAQwA6AFwAVgBvAEkAUABcAEEAZAB2AGUAcgB0
AGkAcwBlAG0AZQBuAHQAIABvAGYAIABTAEkAUAAgAFMAdQBwAHAAbwByAHQAIABiAHkAIABIAC4A
MwAyADMAIABHAGEAdABlAHcAYQB5AHMALgBkAG8AYwAGAEMAQQBHAEIATwBIADoAQwA6AFwAVgBv
AEkAUABcAEEAZAB2AGUAcgB0AGkAcwBlAG0AZQBuAHQAIABvAGYAIABTAEkAUAAgAFMAdQBwAHAA
bwByAHQAIABiAHkAIABIAC4AMwAyADMAIABHAGEAdABlAHcAYQB5AHMALgBkAG8AYwAGAEMAQQBH
AEIATwBIADoAQwA6AFwAVgBvAEkAUABcAEEAZAB2AGUAcgB0AGkAcwBlAG0AZQBuAHQAIABvAGYA
IABTAEkAUAAgAFMAdQBwAHAAbwByAHQAIABiAHkAIABIAC4AMwAyADMAIABHAGEAdABlAHcAYQB5
AHMALgBkAG8AYwAGAEMAQQBHAEIATwBIADoAQwA6AFwAVgBvAEkAUABcAEEAZAB2AGUAcgB0AGkA
cwBlAG0AZQBuAHQAIABvAGYAIABTAEkAUAAgAFMAdQBwAHAAbwByAHQAIABiAHkAIABIAC4AMwAy
ADMAIABHAGEAdABlAHcAYQB5AHMALgBkAG8AYwAGAEMAQQBHAEIATwBIADoAQwA6AFwAVgBvAEkA
UABcAEEAZAB2AGUAcgB0AGkAcwBlAG0AZQBuAHQAIABvAGYAIABTAEkAUAAgAFMAdQBwAHAAbwBy
AHQAIABiAHkAIABIAC4AMwAyADMAIABHAGEAdABlAHcAYQB5AHMALgBkAG8AYwD/QAOAAQByAwAA
cgMAAIzn6QDLAMsAcgMAAAAAAAByAwAAAAAAAAIQAAAAAAAAAGwIAABgAAAIAEAAAAMAAABHFpAB
AAACAgYDBQQFAgMEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABS
AG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0A
YgBvAGwAAAAzJpABAAACCwYEAgICAgIEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAQQByAGkAYQBs
AAAAIgAEAHEIiBgAANACAABoAQAAAACzklGGdppRpgAAAAAJABQAAAA3AQAA8QYAAAEAAwAAAAQA
AxAOAAAAAAAAAAAAAAABAAEAAAABAAAAAAAAAKkCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAKUGwAe0ALQAgAAyMAAAAAAAAAAAAAAAAAAAhggAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD//xIAAAAAAAAA
IQBBAGQAdgBlAHIAdABpAHMAZQBtAGUAbgB0ACAAbwBmACAAUwBJAFAAIABTAHUAcABwAG8AcgB0
ACAAYgB5ACAASAAAAAAAAAAGAEMAQQBHAEIATwBIAAYAQwBBAEcAQgBPAEgAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAA
AAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAhAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAMQA
AAAEAAAA0AAAAAUAAADgAAAABgAAAOwAAAAHAAAA+AAAAAgAAAAIAQAACQAAABgBAAASAAAAJAEA
AAoAAABAAQAADAAAAEwBAAANAAAAWAEAAA4AAABkAQAADwAAAGwBAAAQAAAAdAEAABMAAAB8AQAA
AgAAAOQEAAAeAAAAIgAAAEFkdmVydGlzZW1lbnQgb2YgU0lQIFN1cHBvcnQgYnkgSABvcx4AAAAB
AAAAAGR2ZR4AAAAHAAAAQ0FHQk9IAHMeAAAAAQAAAABBR0IeAAAAAQAAAABBR0IeAAAABwAAAE5v
cm1hbABzHgAAAAcAAABDQUdCT0gAcx4AAAACAAAAOQBHQh4AAAATAAAATWljcm9zb2Z0IFdvcmQg
OC4wAFBAAAAAAHhBywIAAABAAAAAABpyKTSBwAFAAAAAAERhXfWBwAEDAAAAAQAAAAMAAAA3AQAA
AwAAAPEGAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC
1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a5MAQAACAEAAAwAAAABAAAAaAAAAA8A
AABwAAAABQAAAHwAAAAGAAAAhAAAABEAAACMAAAAFwAAAJQAAAALAAAAnAAAABAAAACkAAAAEwAA
AKwAAAAWAAAAtAAAAA0AAAC8AAAADAAAAOoAAAACAAAA5AQAAB4AAAAEAAAAR1RTAAMAAAAOAAAA
AwAAAAMAAAADAAAAhggAAAMAAAAxFQgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAe
EAAAAQAAACIAAABBZHZlcnRpc2VtZW50IG9mIFNJUCBTdXBwb3J0IGJ5IEgADBAAAAIAAAAeAAAA
BgAAAFRpdGxlAAMAAAABAAAAmAAAAAMAAAAAAAAAIAAAAAEAAAA2AAAAAgAAAD4AAAABAAAAAgAA
AAoAAABfUElEX0dVSUQAAgAAAOQEAABBAAAATgAAAHsANQBGAEMANAAzADQARgBBAC0ARQBCAEIA
OQAtADEAMQBEADQALQBBADMAMgA5AC0AMAAwADEAMABBADQAQgA5AEYAMABDAEMAfQAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAK
AAAACwAAAP7///8NAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAA/v///xUAAAAWAAAAFwAAABgA
AAAZAAAAGgAAABsAAAD+////HQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAAP7////9////JgAA
AP7////+/////v//////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAA
RgAAAAAAKGcsNIHAAfA1TXH1gcABKAAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////////8A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAABAAAAAAAABXAG8AcgBkAEQA
bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgAC
AQUAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAeFgAA
AAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAFAAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBv
AHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0
AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA
////////////////AAAAAAAAAAAAAAAAAAAAAAAAAADwNU1x9YHAAfA1TXH1gcABAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAABAAAA/v//////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0
IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAA

------_=_NextPart_000_01C08204.93CB2CE0
Content-Type: text/plain;
	name="Advertisement of SIP by H323GW.txt"
Content-Disposition: attachment;
	filename="Advertisement of SIP by H323GW.txt"
Content-Transfer-Encoding: quoted-printable

Advertisement of SIP Support by H.323 Gateways

As the Session Initiation Protocol (SIP) gains wider acceptance, it is =
important to build gateways that provide an interworking function =
between the two protocols. It is our recommendation that we add SIP to =
the list of supported protocols advertised by an H.323 gateway to its =
gatekeeper."

The semantics of existing desired/supported protocol information =
elements were not appropriate for an H.323 gateway to indicate SIP =
support to an H.323 gatekeeper.  Currently, the best practice for a =
H.323 gateway (supporting SIP) implementation is to use the h323 =
information element in the SupportedProtocols choice for this purpose.  =
The use of such a field means that this H.323 gateway (supporting SIP) =
is a pure H.323 proxy, which is not semantically correct. =20

SupportedProtocols ::=3D CHOICE {
    nonStandardData NonStandardParameter,
    h310 H310Caps,
    h320 H320Caps,
    h321 H321Caps,
    h322 H322Caps,
    h323 H323Caps,
    h324 H324Caps,
    voice VoiceCaps,
    t120-only T120OnlyCaps,
    ...,
    nonStandardProtocol NonStandardProtocol,
    t38FaxAnnexbOnly T38FaxAnnexbOnlyCaps,
    sip SIPCaps
 }

SIPCaps ::=3D SEQUENCE
{
    nonStandardData NonStandardParameter OPTIONAL,
    dataRatesSupported SEQUENCE OF DataRate OPTIONAL,
    supportedPrefixes SEQUENCE OF SupportedPrefix,
    ...
}

CallCapacityInfo ::=3D SEQUENCE {
    voiceGwCallsAvailable SEQUENCE OF CallsAvailable OPTIONAL,
    h310GwCallsAvailable SEQUENCE OF CallsAvailable OPTIONAL,
    h320GwCallsAvailable SEQUENCE OF CallsAvailable OPTIONAL,
    h321GwCallsAvailable SEQUENCE OF CallsAvailable OPTIONAL,
    h322GwCallsAvailable SEQUENCE OF CallsAvailable OPTIONAL,
    h323GwCallsAvailable SEQUENCE OF CallsAvailable OPTIONAL,
    h324GwCallsAvailable SEQUENCE OF CallsAvailable OPTIONAL,
    t120OnlyGwCallsAvailable SEQUENCE OF CallsAvailable OPTIONAL,
    t38FaxAnnexbOnlyGwCallsAvailable SEQUENCE OF CallsAvailable =
OPTIONAL,
    terminalCallsAvailable SEQUENCE OF CallsAvailable OPTIONAL,
    mcuCallsAvailable SEQUENCE OF CallsAvailable OPTIONAL,
    ...,
    sipGwCallsAvailable SEQUENCE OF CallsAvailable OPTIONAL
 }


------_=_NextPart_000_01C08204.93CB2CE0--

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 19 07:07:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27638
	for <sip-archive@odin.ietf.org>; Fri, 19 Jan 2001 07:07:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B9EFC4435D; Fri, 19 Jan 2001 06:08:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id 894AF44336
	for <sip@lists.bell-labs.com>; Fri, 19 Jan 2001 06:07:35 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 19 Jan 2001 12:07:23 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id MAA21850; Fri, 19 Jan 2001 12:06:09 GMT
Message-ID: <3A682DB1.4C12A9D0@ubiquity.net>
From: Neil Deason <ndeason@ubiquity.net>
Organization: Ubiquity Software Corporation Limited
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Removing 409 to conflicting action params
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 19 Jan 2001 12:06:09 +0000
Content-Transfer-Encoding: 7bit

Can we please remove the restriction that all current 
registrations MUST share the same action param. I haven't 
found this to be helpful to either users or implementers. 

The spec doesn't really say anything about servers having 
to obey action params so they could be treated as just a 
hint to the users wishes. A SIP server could then choose 
to try and follow them, use it's own configuration policy 
or follow alternative user defined processing logic (CPL etc).
This is more in keeping with the handling of params like
methods that we are seeing more of in Contact headers.

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 19 10:22:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00416
	for <sip-archive@odin.ietf.org>; Fri, 19 Jan 2001 10:22:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6DB644433C; Fri, 19 Jan 2001 09:23:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 0746344336
	for <sip@lists.bell-labs.com>; Fri, 19 Jan 2001 09:22:16 -0500 (EST)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <CKD5QAJJ>; Fri, 19 Jan 2001 07:21:50 -0800
Message-ID: <E79883AEA37FD411A58C00508BAC5F4B2B5C8E@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Keith Robinson'" <Keith.Robinson@marconi.com>, sip@lists.bell-labs.com
Subject: RE: Outbound Proxies Renewed (was [SIP] Proxy Routing Logic)
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0822B.8A4A65B0"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 19 Jan 2001 07:21:48 -0800

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_01C0822B.8A4A65B0
Content-Type: text/plain;
	charset="iso-8859-1"

> 
> Thanks for reply, even if you didn't agree !

Hi Keith,

I'll agree to the easiest, least brittle method _ I'm just trying to get it
settled. I'm actually having a bit of a change of heart. The reason I didn't
like your (a) suggestion originally [use first Route even if you don't send
to it] was because of maddr's in the Record-Route and the potential problems
they caused with chains. For example Record-Route's of the form:
sip:joe@blow.com;maddr=localproxy. 

If a proxy does not use this format but instead ensures that the
Record-Route will always route to the proxy (eg Record-Route:
<sip:callee@proxy53.proxy.com;state=6867868965454890> ) then I don't see too
much of a problem with removing the Route even if you don't actually send
the message to that address. If the Record-Route globally routes to the
correct proxy then you should be able to send the request to any outbound
proxy without problems - it must get there eventually (and intermediate
proxies shouldn't remove any further Record-Routes).  

Another reason I am having a change of heart from the other suggestion
[leave Route in place until it is used] is that in the case where there is
no Record-Route header (just a Contact) then the UA may have to make a
special case for outbound proxies used for all requests.

Regards,

Robert.


> Considering your proposal of placing the address of the proxy 
> in the R-URI when
> the UA is unable to do the Route mechanism because it lacks 
> DNS; the following
> R-URI may be received by the proxy (serving sipnet.com) in an 
> initial INVITE
> 
> a) sip:userA@sipnet.com
> b) sip:proxy.sipnet.com
> 
> For case a), the userA lies within the domain served by the 
> proxy so the proxy
> must
> perform some type of location service to determine the 
> physical endpoint to
> which
> to send the request.
> 
> For case b), the request is for the domain served by the 
> proxy, but as there is
> no user
> identified it means that this must be a request from a UA 
> that couldn't Route
> using DNS
> so the proxy must do the Routing for it; this suggests that 
> the proxy is
> inferring when it is
> acting as an outbound poxy.
> 
> It appears, then, that the proxy must execute different logic for
> R-URIs that identify the domain the proxy serves but have 
> different formats (or
> perhaps some
> abstract user name for case (b), say 
> outboundroutinglogic@sipnet.com) as opposed
> to
> always performing a location service when it receives an intial INVITE
> identifying that
> domain.
> 
> So, while I agree that this mechanism will, I think it still 
> requires the proxy
> to know when it is acting as an outbound proxy.
> 
> As a counterpoint, perhaps a proxy recognising it is being 
> addressed as an
> outbound proxy
> and then following a set of standard procedures accordingly 
> is not, in fact, the
> wrong thing to do................
> 
> The most important point out of this is that the new 
> Record-Route text needs to
> identify exactly what
> a UA, that can't or won't Route, puts in the R-URI and what 
> it does with the
> Route headers;
> otherwise Record-Route is always going to be problematic when 
> interoperating.
> 
> Regards,
> 
> K. Robinson.
> 
> 
> 
> 
> 
> 
> "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com> on 
> 16/01/2001 10:36:41
>                                                               
>                   
>                                                               
>                   
>                                                               
>                   
> 
> 
>                                                               
>                                                               
>                                                               
>  To:      Keith Robinson/MAIN/MC1@MCMAIN                      
>                                                               
>  cc:      sip@lists.bell-labs.com, Jonathan Rosenberg         
>           <jdrosen@dynamicsoft.com>                           
>                                                               
>                                                               
>                                                               
>  Subject: Outbound Proxies Renewed (was [SIP] Proxy Routing   
>           Logic)                                              
>                                                               
> 
> 
> 
> 
> 
> 
> 
> Trying to revive a stale unresolved thread ...
> 
> Keith Robinson wrote a very good synopsis of the problems but 
> I disagree
> with the conclusions drawn.
> 
> I would also like to reiterate Jonathan's design goals for a 
> solutions: that
> a proxy should not need to know whether it is being used as 
> an outbound
> proxy or have to take special action when being used as a 
> outbound proxy.
> The UA should be responsible for taking any action required 
> (given that the
> UA is the only entity that knows whether it using a proxy as 
> an "outbound
> proxy").
> 
> We seem to have two cases on the UA side:
> 1)   Does not have "Outbound Proxy" configured _or_ only needs to use
> outbound proxy for SIP routing of initial request in a Call Leg.
> 2)   Needs to use outbound proxy for all SIP messages because it lacks
> some ability. Eg DNS.
> 
> And we seem to have three cases on the proxy side. The proxy is
> (unknowlingly) acting as a
> 1)   Normal proxy for UA, may or may not Record-Route.
> 2)   Outbound proxy for UA, no Record-Route needed [eg outbound proxy
> only used for routing initial request]
> 3)   Outbound proxy for UA, needs to Record-route [eg. Firewall-like
> proxy that must be used for all requests]
> 
> I am a proponent of Keith second course of action, that is, 
> the UA does
> _not_ strip the Route if it cannot use it (ie, UA case 2). 
> [And Jonathan's
> original suggestion]. However, I have a slight key 
> modification! If the UA
> sends a message without using the first Route header 
> (assuming one exists),
> then the request-URI is set to the outbound proxy's address !! eg
> sip:proxy_address
> 
> Let me first say that I am not in favor of using 
> Record-Routes of the form
> Record-Route: original_request_uri;maddr=proxy_address.
> Under the new record-route rules this should not be required. 
> The "problem"
> that Keith poses is a good example of why this form of record 
> route is bad.
> Whenever a Route header of this form is used, the maddr is 
> often dropped. A
> proxy that sees the request has no way of knowing whether the 
> Request-URI is
> due to a Route header that the proxy added itself (or not). 
> In the first
> case proxy should use the next route; otherwise I believe it 
> should merely
> forward the request to the Request-URI as written.
> 
> In my mind, it is this problem that causes the difficulties 
> that are being
> experienced.
> 
> The only problematic situation of all the above outbound 
> proxy UA/proxy
> permutations is when the proxy record routes _and_ the UA 
> does not remove
> the record route. (Proxy case 3 & UA case 2). So the first 
> Route entry is
> actually the Route header added by the outbound proxy- but now the
> Request-URI will be equal to the proxy's address.
> 
> A proxy should not gobble/use the next Route header unless 
> the Request-URI
> specifies the proxy itself, right?  So it makes sense that 
> when the proxy is
> (unknowingly) acting as an outbound proxy _and_ the first 
> record-routed
> proxy that you might have to route/process a message twice 
> (logically). The
> UA inserted request-uri ensures that the message is routed to 
> the outbound
> proxy and that the proxy is able to use the next Route entry.
> 
> I don't see it as a problem that the proxy receives a request 
> (to which it
> is the target) and also finds itself in the first Route - it 
> shouldn't break
> things. Spiral routes included. The proxies need to 
> differentiate multiple
> Record-Routes for spiral routes in any case !! The first 
> proxy should see
> itself as the target of the Request-URI (due to UA's actions) 
> which allows
> the proxy to process the next Route header. Finding yourself 
> as the next
> recipient should not break things - its possible for this to 
> occur with
> spiral routes in any case, right?
> 
> This topic brings many of the currently contentious SIP 
> issues out into the
> open: Record-Route mechanism, maddr problems, transparent 
> proxies and of
> course outbound proxies. I'm sure many people will disagree 
> but I thought I
> would at least throw another cat among the pigeons.
> 
> Regards,
> 
> Robert.
> 
> -- My opinions are my own and should not be taken as 
> representing those of
> Nuera Communications, Inc. --
> 
>           -----Original Message-----
>           From:     Keith Robinson [mailto:Keith.Robinson@marconi.com]
>           Sent:     Thursday, January 04, 2001 3:42 AM
>           To:  Jacek_Grabiec@3com.com
>           Cc:  sip@lists.bell-labs.com; billy@billybiggs.com;
> hgs@cs.columbia.edu; Jonathan Rosenberg; rfairlie@nuera.com;
> jhornsby@ubiquity.net; vkg@lucent.com
>           Subject:  RE: [SIP] Proxy Routing Logic
> 
> 
> 
>           The main conflict appears to be when a call stateful proxy,
> which is acting as
>           an outbound proxy for some UAs, record routes.
>           The question for subsequent requests is who does the popping
> of the first ROUTE
>           entry into the R-URI ?
> 
>           For the UA, the two cases are :
> 
>           a) The UA pops the first route entry into the R-URI and
> sends to its outbound
>           proxy
> 
>           or
> 
>           b) The UA sends the request directly to its outbound proxy
> without modifying the
>           Route header and using, say, the URI in TO field as the
> R-URI
> 
>           For case (a) the proxy (serving sipnet.com)  will see
> something like the
>           following
>           (Assume the original request was addressed to
> user1@anothernet.com)
> 
>           INVITE sip:user1@anothernet.com;maddr=proxy.sipnet.com
> 
>           the Route header may or may not be empty dependant on
> whether further
>           downstream proxies have record routed.
> 
>           For case (b) the proxy will receive something like
> 
>           INVITE sip:user1@anothernet.com
>           Route: <sip:user1@anothernet.com;maddr=proxy.sipnet.com>
> 
>           Now,  for case (a), the request will be routed internally to
> the appropriate
>           call state machine
>           using the R-URI, To, From and Call-Id headers. The request
> will be processed and
>           routed to the next server
>           using information obtained from the original INVITE lookup,
> stored CONTACT or
>           the ROUTE header
>           if present.
> 
>           For case (b) the request will be routed internally to the
> appropriate call state
>           machine as for
>           case (a). The request will be processed and routed to the
> next server using the
>           ROUTE header
>           which will send it back to the this proxy, identifying the
> same call state
>           machine as before; at best
>           this will cause the request to be processed twice, at worst
> it could cause
>           problems with state,
>           duplication of output etc,. The situation could be even
> worse if the proxy uses
>           rr-params to store state
>           information to be returned in the R-URI, perhaps for
> identifying spiralled call
>           state machines.
>           To stop this from happening, the proxy would have to perform
> some look ahead
>           processing on the
>           Route header before deciding whether or not to actually use
> the next Route
>           entry, or merely
>           remove it; this is special case processing on the usage of
> the Route header and
>           could become problematic if the proxy appears more than once
> in the Route list
>           due
>           to spiralling.
> 
> 
>           I therefore think that the UA should function as in case (a)
> to eliminate the
>           problems associated with
>           case (b).
> 
>           Now, consider what happens when a UA operating as in case
> (a) sends a subsequent
>           request to
>           its outbound proxy BUT the outbound proxy has deliberately
> NOT record routed
>           because it is not
>           required to keep call state; however, two further downstream
> proxies, serving
>           nextsipnet.com and
>           furthersipnet.com, HAVE record routed.
> 
>           The UA will have constructed a ROUTE header that looks
> something like:
> 
>           Route: <sip:user2@nextsipnet.com;maddr=proxy.nextsipnet.com>
>           Route:
> <sip:user3@furthersipnet.com;maddr=proxy.furthersipnet.com>
> 
>           When the UA sends a subsequent INVITE, because it functions
> as in case (a)
>           it will pop the first Route entry into the R-URI, and send
> this to its outbound
>           proxy
>           as it can't resolve proxy.nextsipnet.com because it has no
> DNS capability.
> 
>           The proxy will receive the following :
> 
>           INVITE sip:user2@nextsipnet.com;maddr=proxy.nextsipnet.com
>           Route:
> <sip:user3@furthersipnet.com;maddr=proxy.furthersipnet.com>
> 
>           And this is the central point of the debate; should the
> proxy route the above
>           request by popping the first route entry into the R-URI, or
> should it use
>           the maddr in the R-URI received. In this case, the proxy
> should clearly
>           route the request using the maddr in the received R-URI,
> otherwise
>           proxy.nextsipnet.com will be bypassed even though it asked
> to be kept
>           in the path; this does, however, represent special case
> processing dependant
>           on the contents of the maddr.
> 
>           If the UA had functioned as in case (b) for the above
> situation, then the proxy
>           would need to route using the Route header.
> 
>           So, special case processing at the proxy appears unavoidable
> no matter
>           whether the UA functions as in case (a) or case (b), and
> whether a proxy that is
>           being used as an outbound proxy has record routed or not. I
> think the question
>           has
>           to be is what special case processing is preferable and what
> are  UA mandated to
>           do with the Route header if they wish to use an outbound
> proxy for subsequent
>           requests.
> 
>           IMO, UAs using an outbound proxy should function as in case
> (a) and proxies
>           should look at the value of the received maddr before
> deciding whether or not
>           to route using the Route header if available. This provides
> for the simplest
>           rules; requiring the proxy to look at the entries in the
> Route header before
>           deciding
>           if it can use the first entry (situation arising through
> case (b) ) seems much
>           more complex
>           and prone to error.
> 
>           The text in 6.34.3 is unclear as to what a UA must do if it
> is using an outbound
>           proxy; I think
>           it will lead to some UA functioning as in case (a) and some
> as in case (b) which
>           is the
>           worst scenario as it becomes almost impossible for proxies
> to know which
>           processing
>           to apply.
> 
>           Also, considering the above and continuing my previous point
> on this thread
>           about
>           a roaming UA wishing to route through the context of its
> home domain proxy I
>           have the following in mind.
> 
>           A UA at visitednet.com has been given proxy.visited.net as
> its local outbound
>           proxy.
>           The UA wishes to set up a call through its home domain proxy
> to
>           friend@anothernet.com.
>           The UA may well construct a Route header to get to
> proxy.homenet.com which looks
>           like:
> 
>           Route <sip:friend@anothernet.com;maddr=proxy.homenet.com>
> 
>           Now, a UA that functions as in case (a) will send the
> following to
>           proxy.visitednet.com
> 
>           INVITE sip:friend@anothernet.com;maddr=proxy.homenet.com
> 
>           The Route header will be empty, as the UA has already popped
> the entry
>           into the R-URI.
> 
>           Upon receiving this request, proxy.visitednet.com (which
> assumes all UA do case
>           (a) )
>           will see that the maddr refererences a domain not served by
> itself and so
>           forward the
>           request to proxy.homenet.com, which will see the request:
> 
>           INVITE sip:friend@anothernet.com;maddr=proxy.homenet.com
> 
>           which is Billy's very first example on this thread.
> 
>           In this case I would want proxy.homenet.com to now route
> using the URI
>           friend@anothernet.com, which was my original point.
> 
>           If the UA functions as in case (b) then proxy.visitednet.com
> (which assumes all
>           UA do case (b) )
>           receives
> 
>           INVITE sip:friend@anothernet.com
>           Route: <sip:friend@anothernet.com;maddr=proxy.homenet.com>
> 
>           proxy.visitednet.com then pops the first Route entry into
> the R-URI and forwards
>           to proxy.homenet.com
>           which receives the following
> 
>           INVITE sip:friend@anothernet.com;maddr=proxy.homenet.com
> 
>           which is exactly the same as if the UA/proxy were
> functioning as in case (a).
> 
>           So, to summarise, assuming UAs function as in case (a), if a
> proxy receives a
>           R-URI
>           with an maddr that does not reference the domain the proxy
> serves then the proxy
>           sends the request to that maddr, regardless of the Route
> headers; if a proxy
>           receives
>           a R-URI with an maddr that does reference the domain it
> serves then it strips
>           the maddr
>           and goes through the normal routing procedures. The only
> special case processing
>           is
>           the result of checking the maddr.
> 
>           Regards,
> 
>           K. Robinson.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>           Jacek_Grabiec@3com.com on 02/01/2001 15:07:13
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>            To:      sip@lists.bell-labs.com
> 
> 
> 
>            cc:      billy@billybiggs.com, hgs@cs.columbia.edu,
> Jonathan
>                     Rosenberg <jdrosen@dynamicsoft.com>,
> 
>                     rfairlie@nuera.com, jhornsby@ubiquity.net,
> 
>                     vkg@lucent.com(bcc: Keith Robinson/MAIN/MC1)
> 
> 
> 
> 
> 
> 
> 
>            Subject: RE: [SIP] Proxy Routing Logic
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>           Jonathan Rosenberg wrote;
>           >To comment on the primary issue, ignoring the Route header
> if the request
>           >URI domain is not your own, and sending it to that domain
> first, is
>           >dangerous, IMHO. Thats because, nearly as I can tell, it
> completely breaks
>           >the existing usage of record-routing. In the existing
> usage, a proxy copies
>           >the request URI in the request into the record-route, and
> adds its own
>           >maddr. Requests in the reverse direction will only get
> routed correctly
>           >through that same set of proxies IFF each proxy uses the
> top route header no
>           >matter what. If proxies start to only sometimes use them,
> we will end up
>           >with incorrectly routed requests.
> 
>           I'm not sure if 'ignoring the Route header if the request
>           URI domain is not your own, and sending it to that domain
> first' breaks
>           anything.
>           I can see it may add another proxy to the path, but at least
> all record-routed
>           Proxies are on the path as well. Doing otherwise will break
> routing (I gave an
>           example
>           in one of my previuos postings). I would argue that proxy
> cannot blindly follow
>           logic 'replace RURI with Route' no matter what just like it
> does not proxy
>           responses
>           downstream if top-via doesn't match the server - it checks
> if it matches first.
> 
>           >So, I would modify my proposal to satisfy some of the other
> requirements:
> 
>           >1. If there is a Route header in a request, that ALWAYS
> takes priority for
>           >routing the request.
>           >2. If there is none, and the request URI has a domain NOT
> matching that of
>           >the server, but the address/domain in the maddr does, the
> server forwards to
>           >the domain in the userhost portion of the R-URI. If the
> neither the maddr or
>           >userhost have an ipaddress/domain matching the proxy, the
> proxy sends the
>           >request to the address in the maddr. Stripping of maddr is
> optional.
> 
>           your 2 suggestion is really close what I would have in mind.
> There's also
>           another
>           scenario: where Proxy receives a request with maddr where
> neither maddr nor host
>           portion of RURI matches the server.
> 
>           Let's say proxy at sip.company.com receives a requests like:
> 
>           sip:abc@someone-else.com;maddr=proxy.com
>           .......
>           Route:
> <sip:123@yet-someone-else.com;maddr=yet-yet-someone-else.com>
> 
>           As Billy pointed out you, being the proxy, don't really want
> to pop Route header
>            blindly. I would rather
>           propose something along theses lines - it is really close to
> your 2 case (it
>           also takes care of scenario where
>           Proxy has it's own outbound Proxy which may have its own
> outbound Proxy etc - if
>            you were to pop Route at
>           every hop the message would never get to the proper
> Proxies):
>           Investigate RURI first:
>           1)   if maddr exist and it doesn't match your domain send
> message to:
>                - address indicated in maddr and strip maddr.
>                - or, if outbound Proxy is used, to outbound Proxy and
> preserve maddr
>                - or, return 488 if unwilling/unable to forward the
> request (I explained my
>            reasoning for 488 in previous posting)
>           2)   if maddr exist and it matches your domain strip maddr
> and go to 3
>           3)   if host part of RURI doesn't match your domain send
> message to:
>                - address indicated in host part of RURI and preserve
> existing RURI and
>           Route(s),
>                - or, if outbound Proxy is used, to outbound Proxy and
> preserve existing
>           RURI and Route(s),
>           4)   if host part of RURI does match your domain pop first
> Route header and go
>           back to 1
>                (now your RURI is whatever Route header contained).
>           5)   if there's no Route header do whatever you want (get
> contact from your
>                location/registrar server most likely) and go back to 1
> (now RURI is
>           whatever you got
>                from location/registrar server)
> 
> 
>           regards, Jacek Grabiec
>           sip:jacek_grabiec@sip.3com.com
> 
> 
> 
>           _______________________________________________
>           SIP mailing list
>           SIP@lists.bell-labs.com
>           http://lists.bell-labs.com/mailman/listinfo/sip
> 
> 
> 
> 

------_=_NextPart_001_01C0822B.8A4A65B0
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Outbound Proxies Renewed (was [SIP] Proxy Routing =
Logic)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks for reply, even if you didn't agree =
!</FONT>
</P>

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

<P><FONT SIZE=3D2>I'll agree to the easiest, least brittle method _ I'm =
just trying to get it settled. I'm actually having a bit of a change of =
heart. The reason I didn't like your (a) suggestion originally [use =
first Route even if you don't send to it] was because of maddr's in the =
Record-Route and the potential problems they caused with chains. For =
example Record-Route's of the form: =
sip:joe@blow.com;maddr=3Dlocalproxy. </FONT></P>

<P><FONT SIZE=3D2>If a proxy does not use this format but instead =
ensures that the Record-Route will always route to the proxy (eg =
Record-Route: =
&lt;sip:callee@proxy53.proxy.com;state=3D6867868965454890&gt; ) then I =
don't see too much of a problem with removing the Route even if you =
don't actually send the message to that address. If the Record-Route =
globally routes to the correct proxy then you should be able to send =
the request to any outbound proxy without problems - it must get there =
eventually (and intermediate proxies shouldn't remove any further =
Record-Routes).&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Another reason I am having a change of heart from the =
other suggestion [leave Route in place until it is used] is that in the =
case where there is no Record-Route header (just a Contact) then the UA =
may have to make a special case for outbound proxies used for all =
requests.</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Robert.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; Considering your proposal of placing the address =
of the proxy </FONT>
<BR><FONT SIZE=3D2>&gt; in the R-URI when</FONT>
<BR><FONT SIZE=3D2>&gt; the UA is unable to do the Route mechanism =
because it lacks </FONT>
<BR><FONT SIZE=3D2>&gt; DNS; the following</FONT>
<BR><FONT SIZE=3D2>&gt; R-URI may be received by the proxy (serving =
sipnet.com) in an </FONT>
<BR><FONT SIZE=3D2>&gt; initial INVITE</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; a) sip:userA@sipnet.com</FONT>
<BR><FONT SIZE=3D2>&gt; b) sip:proxy.sipnet.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; For case a), the userA lies within the domain =
served by the </FONT>
<BR><FONT SIZE=3D2>&gt; proxy so the proxy</FONT>
<BR><FONT SIZE=3D2>&gt; must</FONT>
<BR><FONT SIZE=3D2>&gt; perform some type of location service to =
determine the </FONT>
<BR><FONT SIZE=3D2>&gt; physical endpoint to</FONT>
<BR><FONT SIZE=3D2>&gt; which</FONT>
<BR><FONT SIZE=3D2>&gt; to send the request.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; For case b), the request is for the domain =
served by the </FONT>
<BR><FONT SIZE=3D2>&gt; proxy, but as there is</FONT>
<BR><FONT SIZE=3D2>&gt; no user</FONT>
<BR><FONT SIZE=3D2>&gt; identified it means that this must be a request =
from a UA </FONT>
<BR><FONT SIZE=3D2>&gt; that couldn't Route</FONT>
<BR><FONT SIZE=3D2>&gt; using DNS</FONT>
<BR><FONT SIZE=3D2>&gt; so the proxy must do the Routing for it; this =
suggests that </FONT>
<BR><FONT SIZE=3D2>&gt; the proxy is</FONT>
<BR><FONT SIZE=3D2>&gt; inferring when it is</FONT>
<BR><FONT SIZE=3D2>&gt; acting as an outbound poxy.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It appears, then, that the proxy must execute =
different logic for</FONT>
<BR><FONT SIZE=3D2>&gt; R-URIs that identify the domain the proxy =
serves but have </FONT>
<BR><FONT SIZE=3D2>&gt; different formats (or</FONT>
<BR><FONT SIZE=3D2>&gt; perhaps some</FONT>
<BR><FONT SIZE=3D2>&gt; abstract user name for case (b), say </FONT>
<BR><FONT SIZE=3D2>&gt; outboundroutinglogic@sipnet.com) as =
opposed</FONT>
<BR><FONT SIZE=3D2>&gt; to</FONT>
<BR><FONT SIZE=3D2>&gt; always performing a location service when it =
receives an intial INVITE</FONT>
<BR><FONT SIZE=3D2>&gt; identifying that</FONT>
<BR><FONT SIZE=3D2>&gt; domain.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So, while I agree that this mechanism will, I =
think it still </FONT>
<BR><FONT SIZE=3D2>&gt; requires the proxy</FONT>
<BR><FONT SIZE=3D2>&gt; to know when it is acting as an outbound =
proxy.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As a counterpoint, perhaps a proxy recognising =
it is being </FONT>
<BR><FONT SIZE=3D2>&gt; addressed as an</FONT>
<BR><FONT SIZE=3D2>&gt; outbound proxy</FONT>
<BR><FONT SIZE=3D2>&gt; and then following a set of standard procedures =
accordingly </FONT>
<BR><FONT SIZE=3D2>&gt; is not, in fact, the</FONT>
<BR><FONT SIZE=3D2>&gt; wrong thing to do................</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The most important point out of this is that =
the new </FONT>
<BR><FONT SIZE=3D2>&gt; Record-Route text needs to</FONT>
<BR><FONT SIZE=3D2>&gt; identify exactly what</FONT>
<BR><FONT SIZE=3D2>&gt; a UA, that can't or won't Route, puts in the =
R-URI and what </FONT>
<BR><FONT SIZE=3D2>&gt; it does with the</FONT>
<BR><FONT SIZE=3D2>&gt; Route headers;</FONT>
<BR><FONT SIZE=3D2>&gt; otherwise Record-Route is always going to be =
problematic when </FONT>
<BR><FONT SIZE=3D2>&gt; interoperating.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; K. Robinson.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;Fairlie-Cuninghame, Robert&quot; =
&lt;rfairlie@nuera.com&gt; on </FONT>
<BR><FONT SIZE=3D2>&gt; 16/01/2001 10:36:41</FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; To:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Keith =
Robinson/MAIN/MC1@MCMAIN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; cc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
sip@lists.bell-labs.com, Jonathan =
Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; =
&lt;jdrosen@dynamicsoft.com&gt;&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; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Subject: Outbound Proxies Renewed (was =
[SIP] Proxy Routing&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; =
Logic)&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Trying to revive a stale unresolved thread =
...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Keith Robinson wrote a very good synopsis of =
the problems but </FONT>
<BR><FONT SIZE=3D2>&gt; I disagree</FONT>
<BR><FONT SIZE=3D2>&gt; with the conclusions drawn.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I would also like to reiterate Jonathan's =
design goals for a </FONT>
<BR><FONT SIZE=3D2>&gt; solutions: that</FONT>
<BR><FONT SIZE=3D2>&gt; a proxy should not need to know whether it is =
being used as </FONT>
<BR><FONT SIZE=3D2>&gt; an outbound</FONT>
<BR><FONT SIZE=3D2>&gt; proxy or have to take special action when being =
used as a </FONT>
<BR><FONT SIZE=3D2>&gt; outbound proxy.</FONT>
<BR><FONT SIZE=3D2>&gt; The UA should be responsible for taking any =
action required </FONT>
<BR><FONT SIZE=3D2>&gt; (given that the</FONT>
<BR><FONT SIZE=3D2>&gt; UA is the only entity that knows whether it =
using a proxy as </FONT>
<BR><FONT SIZE=3D2>&gt; an &quot;outbound</FONT>
<BR><FONT SIZE=3D2>&gt; proxy&quot;).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; We seem to have two cases on the UA =
side:</FONT>
<BR><FONT SIZE=3D2>&gt; 1)&nbsp;&nbsp; Does not have &quot;Outbound =
Proxy&quot; configured _or_ only needs to use</FONT>
<BR><FONT SIZE=3D2>&gt; outbound proxy for SIP routing of initial =
request in a Call Leg.</FONT>
<BR><FONT SIZE=3D2>&gt; 2)&nbsp;&nbsp; Needs to use outbound proxy for =
all SIP messages because it lacks</FONT>
<BR><FONT SIZE=3D2>&gt; some ability. Eg DNS.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; And we seem to have three cases on the proxy =
side. The proxy is</FONT>
<BR><FONT SIZE=3D2>&gt; (unknowlingly) acting as a</FONT>
<BR><FONT SIZE=3D2>&gt; 1)&nbsp;&nbsp; Normal proxy for UA, may or may =
not Record-Route.</FONT>
<BR><FONT SIZE=3D2>&gt; 2)&nbsp;&nbsp; Outbound proxy for UA, no =
Record-Route needed [eg outbound proxy</FONT>
<BR><FONT SIZE=3D2>&gt; only used for routing initial request]</FONT>
<BR><FONT SIZE=3D2>&gt; 3)&nbsp;&nbsp; Outbound proxy for UA, needs to =
Record-route [eg. Firewall-like</FONT>
<BR><FONT SIZE=3D2>&gt; proxy that must be used for all =
requests]</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I am a proponent of Keith second course of =
action, that is, </FONT>
<BR><FONT SIZE=3D2>&gt; the UA does</FONT>
<BR><FONT SIZE=3D2>&gt; _not_ strip the Route if it cannot use it (ie, =
UA case 2). </FONT>
<BR><FONT SIZE=3D2>&gt; [And Jonathan's</FONT>
<BR><FONT SIZE=3D2>&gt; original suggestion]. However, I have a slight =
key </FONT>
<BR><FONT SIZE=3D2>&gt; modification! If the UA</FONT>
<BR><FONT SIZE=3D2>&gt; sends a message without using the first Route =
header </FONT>
<BR><FONT SIZE=3D2>&gt; (assuming one exists),</FONT>
<BR><FONT SIZE=3D2>&gt; then the request-URI is set to the outbound =
proxy's address !! eg</FONT>
<BR><FONT SIZE=3D2>&gt; sip:proxy_address</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Let me first say that I am not in favor of =
using </FONT>
<BR><FONT SIZE=3D2>&gt; Record-Routes of the form</FONT>
<BR><FONT SIZE=3D2>&gt; Record-Route: =
original_request_uri;maddr=3Dproxy_address.</FONT>
<BR><FONT SIZE=3D2>&gt; Under the new record-route rules this should =
not be required. </FONT>
<BR><FONT SIZE=3D2>&gt; The &quot;problem&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; that Keith poses is a good example of why this =
form of record </FONT>
<BR><FONT SIZE=3D2>&gt; route is bad.</FONT>
<BR><FONT SIZE=3D2>&gt; Whenever a Route header of this form is used, =
the maddr is </FONT>
<BR><FONT SIZE=3D2>&gt; often dropped. A</FONT>
<BR><FONT SIZE=3D2>&gt; proxy that sees the request has no way of =
knowing whether the </FONT>
<BR><FONT SIZE=3D2>&gt; Request-URI is</FONT>
<BR><FONT SIZE=3D2>&gt; due to a Route header that the proxy added =
itself (or not). </FONT>
<BR><FONT SIZE=3D2>&gt; In the first</FONT>
<BR><FONT SIZE=3D2>&gt; case proxy should use the next route; otherwise =
I believe it </FONT>
<BR><FONT SIZE=3D2>&gt; should merely</FONT>
<BR><FONT SIZE=3D2>&gt; forward the request to the Request-URI as =
written.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In my mind, it is this problem that causes the =
difficulties </FONT>
<BR><FONT SIZE=3D2>&gt; that are being</FONT>
<BR><FONT SIZE=3D2>&gt; experienced.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The only problematic situation of all the above =
outbound </FONT>
<BR><FONT SIZE=3D2>&gt; proxy UA/proxy</FONT>
<BR><FONT SIZE=3D2>&gt; permutations is when the proxy record routes =
_and_ the UA </FONT>
<BR><FONT SIZE=3D2>&gt; does not remove</FONT>
<BR><FONT SIZE=3D2>&gt; the record route. (Proxy case 3 &amp; UA case =
2). So the first </FONT>
<BR><FONT SIZE=3D2>&gt; Route entry is</FONT>
<BR><FONT SIZE=3D2>&gt; actually the Route header added by the outbound =
proxy- but now the</FONT>
<BR><FONT SIZE=3D2>&gt; Request-URI will be equal to the proxy's =
address.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A proxy should not gobble/use the next Route =
header unless </FONT>
<BR><FONT SIZE=3D2>&gt; the Request-URI</FONT>
<BR><FONT SIZE=3D2>&gt; specifies the proxy itself, right?&nbsp; So it =
makes sense that </FONT>
<BR><FONT SIZE=3D2>&gt; when the proxy is</FONT>
<BR><FONT SIZE=3D2>&gt; (unknowingly) acting as an outbound proxy _and_ =
the first </FONT>
<BR><FONT SIZE=3D2>&gt; record-routed</FONT>
<BR><FONT SIZE=3D2>&gt; proxy that you might have to route/process a =
message twice </FONT>
<BR><FONT SIZE=3D2>&gt; (logically). The</FONT>
<BR><FONT SIZE=3D2>&gt; UA inserted request-uri ensures that the =
message is routed to </FONT>
<BR><FONT SIZE=3D2>&gt; the outbound</FONT>
<BR><FONT SIZE=3D2>&gt; proxy and that the proxy is able to use the =
next Route entry.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I don't see it as a problem that the proxy =
receives a request </FONT>
<BR><FONT SIZE=3D2>&gt; (to which it</FONT>
<BR><FONT SIZE=3D2>&gt; is the target) and also finds itself in the =
first Route - it </FONT>
<BR><FONT SIZE=3D2>&gt; shouldn't break</FONT>
<BR><FONT SIZE=3D2>&gt; things. Spiral routes included. The proxies =
need to </FONT>
<BR><FONT SIZE=3D2>&gt; differentiate multiple</FONT>
<BR><FONT SIZE=3D2>&gt; Record-Routes for spiral routes in any case !! =
The first </FONT>
<BR><FONT SIZE=3D2>&gt; proxy should see</FONT>
<BR><FONT SIZE=3D2>&gt; itself as the target of the Request-URI (due to =
UA's actions) </FONT>
<BR><FONT SIZE=3D2>&gt; which allows</FONT>
<BR><FONT SIZE=3D2>&gt; the proxy to process the next Route header. =
Finding yourself </FONT>
<BR><FONT SIZE=3D2>&gt; as the next</FONT>
<BR><FONT SIZE=3D2>&gt; recipient should not break things - its =
possible for this to </FONT>
<BR><FONT SIZE=3D2>&gt; occur with</FONT>
<BR><FONT SIZE=3D2>&gt; spiral routes in any case, right?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This topic brings many of the currently =
contentious SIP </FONT>
<BR><FONT SIZE=3D2>&gt; issues out into the</FONT>
<BR><FONT SIZE=3D2>&gt; open: Record-Route mechanism, maddr problems, =
transparent </FONT>
<BR><FONT SIZE=3D2>&gt; proxies and of</FONT>
<BR><FONT SIZE=3D2>&gt; course outbound proxies. I'm sure many people =
will disagree </FONT>
<BR><FONT SIZE=3D2>&gt; but I thought I</FONT>
<BR><FONT SIZE=3D2>&gt; would at least throw another cat among the =
pigeons.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Robert.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -- My opinions are my own and should not be =
taken as </FONT>
<BR><FONT SIZE=3D2>&gt; representing those of</FONT>
<BR><FONT SIZE=3D2>&gt; Nuera Communications, Inc. --</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; -----Original Message-----</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; From:&nbsp;&nbsp;&nbsp;&nbsp; Keith Robinson [<A =
HREF=3D"mailto:Keith.Robinson@marconi.com">mailto:Keith.Robinson@marconi=
.com</A>]</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Sent:&nbsp;&nbsp;&nbsp;&nbsp; Thursday, January 04, 2001 3:42 =
AM</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; To:&nbsp; Jacek_Grabiec@3com.com</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Cc:&nbsp; sip@lists.bell-labs.com; billy@billybiggs.com;</FONT>
<BR><FONT SIZE=3D2>&gt; hgs@cs.columbia.edu; Jonathan Rosenberg; =
rfairlie@nuera.com;</FONT>
<BR><FONT SIZE=3D2>&gt; jhornsby@ubiquity.net; vkg@lucent.com</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Subject:&nbsp; RE: [SIP] Proxy Routing Logic</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; The main conflict appears to be when a call stateful proxy,</FONT>
<BR><FONT SIZE=3D2>&gt; which is acting as</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; an outbound proxy for some UAs, record routes.</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; The question for subsequent requests is who does the popping</FONT>
<BR><FONT SIZE=3D2>&gt; of the first ROUTE</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; entry into the R-URI ?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; For the UA, the two cases are :</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; a) The UA pops the first route entry into the R-URI and</FONT>
<BR><FONT SIZE=3D2>&gt; sends to its outbound</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; proxy</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; or</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; b) The UA sends the request directly to its outbound proxy</FONT>
<BR><FONT SIZE=3D2>&gt; without modifying the</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Route header and using, say, the URI in TO field as the</FONT>
<BR><FONT SIZE=3D2>&gt; R-URI</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; For case (a) the proxy (serving sipnet.com)&nbsp; will see</FONT>
<BR><FONT SIZE=3D2>&gt; something like the</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; following</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; (Assume the original request was addressed to</FONT>
<BR><FONT SIZE=3D2>&gt; user1@anothernet.com)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; INVITE sip:user1@anothernet.com;maddr=3Dproxy.sipnet.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; the Route header may or may not be empty dependant on</FONT>
<BR><FONT SIZE=3D2>&gt; whether further</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; downstream proxies have record routed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; For case (b) the proxy will receive something like</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; INVITE sip:user1@anothernet.com</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Route: &lt;sip:user1@anothernet.com;maddr=3Dproxy.sipnet.com&gt;</FONT=
>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Now,&nbsp; for case (a), the request will be routed internally =
to</FONT>
<BR><FONT SIZE=3D2>&gt; the appropriate</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; call state machine</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; using the R-URI, To, From and Call-Id headers. The request</FONT>
<BR><FONT SIZE=3D2>&gt; will be processed and</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; routed to the next server</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; using information obtained from the original INVITE lookup,</FONT>
<BR><FONT SIZE=3D2>&gt; stored CONTACT or</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; the ROUTE header</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; if present.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; For case (b) the request will be routed internally to the</FONT>
<BR><FONT SIZE=3D2>&gt; appropriate call state</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; machine as for</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; case (a). The request will be processed and routed to the</FONT>
<BR><FONT SIZE=3D2>&gt; next server using the</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; ROUTE header</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; which will send it back to the this proxy, identifying the</FONT>
<BR><FONT SIZE=3D2>&gt; same call state</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; machine as before; at best</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; this will cause the request to be processed twice, at worst</FONT>
<BR><FONT SIZE=3D2>&gt; it could cause</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; problems with state,</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; duplication of output etc,. The situation could be even</FONT>
<BR><FONT SIZE=3D2>&gt; worse if the proxy uses</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; rr-params to store state</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; information to be returned in the R-URI, perhaps for</FONT>
<BR><FONT SIZE=3D2>&gt; identifying spiralled call</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; state machines.</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; To stop this from happening, the proxy would have to perform</FONT>
<BR><FONT SIZE=3D2>&gt; some look ahead</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; processing on the</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Route header before deciding whether or not to actually use</FONT>
<BR><FONT SIZE=3D2>&gt; the next Route</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; entry, or merely</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; remove it; this is special case processing on the usage of</FONT>
<BR><FONT SIZE=3D2>&gt; the Route header and</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; could become problematic if the proxy appears more than once</FONT>
<BR><FONT SIZE=3D2>&gt; in the Route list</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; due</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; to spiralling.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; I therefore think that the UA should function as in case (a)</FONT>
<BR><FONT SIZE=3D2>&gt; to eliminate the</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; problems associated with</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; case (b).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Now, consider what happens when a UA operating as in case</FONT>
<BR><FONT SIZE=3D2>&gt; (a) sends a subsequent</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; request to</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; its outbound proxy BUT the outbound proxy has deliberately</FONT>
<BR><FONT SIZE=3D2>&gt; NOT record routed</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; because it is not</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; required to keep call state; however, two further downstream</FONT>
<BR><FONT SIZE=3D2>&gt; proxies, serving</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; nextsipnet.com and</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; furthersipnet.com, HAVE record routed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; The UA will have constructed a ROUTE header that looks</FONT>
<BR><FONT SIZE=3D2>&gt; something like:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Route: =
&lt;sip:user2@nextsipnet.com;maddr=3Dproxy.nextsipnet.com&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Route:</FONT>
<BR><FONT SIZE=3D2>&gt; =
&lt;sip:user3@furthersipnet.com;maddr=3Dproxy.furthersipnet.com&gt;</FON=
T>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; When the UA sends a subsequent INVITE, because it functions</FONT>
<BR><FONT SIZE=3D2>&gt; as in case (a)</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; it will pop the first Route entry into the R-URI, and send</FONT>
<BR><FONT SIZE=3D2>&gt; this to its outbound</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; proxy</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; as it can't resolve proxy.nextsipnet.com because it has no</FONT>
<BR><FONT SIZE=3D2>&gt; DNS capability.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; The proxy will receive the following :</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; INVITE sip:user2@nextsipnet.com;maddr=3Dproxy.nextsipnet.com</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Route:</FONT>
<BR><FONT SIZE=3D2>&gt; =
&lt;sip:user3@furthersipnet.com;maddr=3Dproxy.furthersipnet.com&gt;</FON=
T>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; And this is the central point of the debate; should the</FONT>
<BR><FONT SIZE=3D2>&gt; proxy route the above</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; request by popping the first route entry into the R-URI, or</FONT>
<BR><FONT SIZE=3D2>&gt; should it use</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; the maddr in the R-URI received. In this case, the proxy</FONT>
<BR><FONT SIZE=3D2>&gt; should clearly</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; route the request using the maddr in the received R-URI,</FONT>
<BR><FONT SIZE=3D2>&gt; otherwise</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; proxy.nextsipnet.com will be bypassed even though it asked</FONT>
<BR><FONT SIZE=3D2>&gt; to be kept</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; in the path; this does, however, represent special case</FONT>
<BR><FONT SIZE=3D2>&gt; processing dependant</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; on the contents of the maddr.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; If the UA had functioned as in case (b) for the above</FONT>
<BR><FONT SIZE=3D2>&gt; situation, then the proxy</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; would need to route using the Route header.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; So, special case processing at the proxy appears unavoidable</FONT>
<BR><FONT SIZE=3D2>&gt; no matter</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; whether the UA functions as in case (a) or case (b), and</FONT>
<BR><FONT SIZE=3D2>&gt; whether a proxy that is</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; being used as an outbound proxy has record routed or not. I</FONT>
<BR><FONT SIZE=3D2>&gt; think the question</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; has</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; to be is what special case processing is preferable and what</FONT>
<BR><FONT SIZE=3D2>&gt; are&nbsp; UA mandated to</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; do with the Route header if they wish to use an outbound</FONT>
<BR><FONT SIZE=3D2>&gt; proxy for subsequent</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; requests.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; IMO, UAs using an outbound proxy should function as in case</FONT>
<BR><FONT SIZE=3D2>&gt; (a) and proxies</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; should look at the value of the received maddr before</FONT>
<BR><FONT SIZE=3D2>&gt; deciding whether or not</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; to route using the Route header if available. This provides</FONT>
<BR><FONT SIZE=3D2>&gt; for the simplest</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; rules; requiring the proxy to look at the entries in the</FONT>
<BR><FONT SIZE=3D2>&gt; Route header before</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; deciding</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; if it can use the first entry (situation arising through</FONT>
<BR><FONT SIZE=3D2>&gt; case (b) ) seems much</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; more complex</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; and prone to error.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; The text in 6.34.3 is unclear as to what a UA must do if it</FONT>
<BR><FONT SIZE=3D2>&gt; is using an outbound</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; proxy; I think</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; it will lead to some UA functioning as in case (a) and =
some</FONT>
<BR><FONT SIZE=3D2>&gt; as in case (b) which</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; is the</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; worst scenario as it becomes almost impossible for proxies</FONT>
<BR><FONT SIZE=3D2>&gt; to know which</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; processing</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; to apply.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Also, considering the above and continuing my previous point</FONT>
<BR><FONT SIZE=3D2>&gt; on this thread</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; about</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; a roaming UA wishing to route through the context of its</FONT>
<BR><FONT SIZE=3D2>&gt; home domain proxy I</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; have the following in mind.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; A UA at visitednet.com has been given proxy.visited.net as</FONT>
<BR><FONT SIZE=3D2>&gt; its local outbound</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; proxy.</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; The UA wishes to set up a call through its home domain proxy</FONT>
<BR><FONT SIZE=3D2>&gt; to</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; friend@anothernet.com.</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; The UA may well construct a Route header to get to</FONT>
<BR><FONT SIZE=3D2>&gt; proxy.homenet.com which looks</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; like:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Route =
&lt;sip:friend@anothernet.com;maddr=3Dproxy.homenet.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Now, a UA that functions as in case (a) will send the</FONT>
<BR><FONT SIZE=3D2>&gt; following to</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; proxy.visitednet.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; INVITE sip:friend@anothernet.com;maddr=3Dproxy.homenet.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; The Route header will be empty, as the UA has already popped</FONT>
<BR><FONT SIZE=3D2>&gt; the entry</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; into the R-URI.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Upon receiving this request, proxy.visitednet.com (which</FONT>
<BR><FONT SIZE=3D2>&gt; assumes all UA do case</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; (a) )</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; will see that the maddr refererences a domain not served by</FONT>
<BR><FONT SIZE=3D2>&gt; itself and so</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; forward the</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; request to proxy.homenet.com, which will see the request:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; INVITE sip:friend@anothernet.com;maddr=3Dproxy.homenet.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; which is Billy's very first example on this thread.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; In this case I would want proxy.homenet.com to now route</FONT>
<BR><FONT SIZE=3D2>&gt; using the URI</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; friend@anothernet.com, which was my original point.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; If the UA functions as in case (b) then proxy.visitednet.com</FONT>
<BR><FONT SIZE=3D2>&gt; (which assumes all</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; UA do case (b) )</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; receives</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; INVITE sip:friend@anothernet.com</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Route: =
&lt;sip:friend@anothernet.com;maddr=3Dproxy.homenet.com&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; proxy.visitednet.com then pops the first Route entry into</FONT>
<BR><FONT SIZE=3D2>&gt; the R-URI and forwards</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; to proxy.homenet.com</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; which receives the following</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; INVITE sip:friend@anothernet.com;maddr=3Dproxy.homenet.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; which is exactly the same as if the UA/proxy were</FONT>
<BR><FONT SIZE=3D2>&gt; functioning as in case (a).</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; So, to summarise, assuming UAs function as in case (a), if a</FONT>
<BR><FONT SIZE=3D2>&gt; proxy receives a</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; R-URI</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; with an maddr that does not reference the domain the proxy</FONT>
<BR><FONT SIZE=3D2>&gt; serves then the proxy</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; sends the request to that maddr, regardless of the Route</FONT>
<BR><FONT SIZE=3D2>&gt; headers; if a proxy</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; receives</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; a R-URI with an maddr that does reference the domain it</FONT>
<BR><FONT SIZE=3D2>&gt; serves then it strips</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; the maddr</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; and goes through the normal routing procedures. The only</FONT>
<BR><FONT SIZE=3D2>&gt; special case processing</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; is</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; the result of checking the maddr.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp; K. Robinson.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Jacek_Grabiec@3com.com on 02/01/2001 15:07:13</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; To:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
sip@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; cc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; billy@billybiggs.com, =
hgs@cs.columbia.edu,</FONT>
<BR><FONT SIZE=3D2>&gt; Jonathan</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Rosenberg =
&lt;jdrosen@dynamicsoft.com&gt;,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
rfairlie@nuera.com, jhornsby@ubiquity.net,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
vkg@lucent.com(bcc: Keith Robinson/MAIN/MC1)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; Subject: RE: [SIP] Proxy Routing Logic</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Jonathan Rosenberg wrote;</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &gt;To comment on the primary issue, ignoring the Route header</FONT>
<BR><FONT SIZE=3D2>&gt; if the request</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &gt;URI domain is not your own, and sending it to that domain</FONT>
<BR><FONT SIZE=3D2>&gt; first, is</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &gt;dangerous, IMHO. Thats because, nearly as I can tell, it</FONT>
<BR><FONT SIZE=3D2>&gt; completely breaks</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &gt;the existing usage of record-routing. In the existing</FONT>
<BR><FONT SIZE=3D2>&gt; usage, a proxy copies</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &gt;the request URI in the request into the record-route, and</FONT>
<BR><FONT SIZE=3D2>&gt; adds its own</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &gt;maddr. Requests in the reverse direction will only get</FONT>
<BR><FONT SIZE=3D2>&gt; routed correctly</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &gt;through that same set of proxies IFF each proxy uses the</FONT>
<BR><FONT SIZE=3D2>&gt; top route header no</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &gt;matter what. If proxies start to only sometimes use them,</FONT>
<BR><FONT SIZE=3D2>&gt; we will end up</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &gt;with incorrectly routed requests.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; I'm not sure if 'ignoring the Route header if the request</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; URI domain is not your own, and sending it to that domain</FONT>
<BR><FONT SIZE=3D2>&gt; first' breaks</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; anything.</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; I can see it may add another proxy to the path, but at least</FONT>
<BR><FONT SIZE=3D2>&gt; all record-routed</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Proxies are on the path as well. Doing otherwise will break</FONT>
<BR><FONT SIZE=3D2>&gt; routing (I gave an</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; example</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; in one of my previuos postings). I would argue that proxy</FONT>
<BR><FONT SIZE=3D2>&gt; cannot blindly follow</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; logic 'replace RURI with Route' no matter what just like it</FONT>
<BR><FONT SIZE=3D2>&gt; does not proxy</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; responses</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; downstream if top-via doesn't match the server - it checks</FONT>
<BR><FONT SIZE=3D2>&gt; if it matches first.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &gt;So, I would modify my proposal to satisfy some of the =
other</FONT>
<BR><FONT SIZE=3D2>&gt; requirements:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &gt;1. If there is a Route header in a request, that ALWAYS</FONT>
<BR><FONT SIZE=3D2>&gt; takes priority for</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &gt;routing the request.</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &gt;2. If there is none, and the request URI has a domain NOT</FONT>
<BR><FONT SIZE=3D2>&gt; matching that of</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &gt;the server, but the address/domain in the maddr does, the</FONT>
<BR><FONT SIZE=3D2>&gt; server forwards to</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &gt;the domain in the userhost portion of the R-URI. If the</FONT>
<BR><FONT SIZE=3D2>&gt; neither the maddr or</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &gt;userhost have an ipaddress/domain matching the proxy, the</FONT>
<BR><FONT SIZE=3D2>&gt; proxy sends the</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; &gt;request to the address in the maddr. Stripping of maddr is</FONT>
<BR><FONT SIZE=3D2>&gt; optional.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; your 2 suggestion is really close what I would have in mind.</FONT>
<BR><FONT SIZE=3D2>&gt; There's also</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; another</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; scenario: where Proxy receives a request with maddr where</FONT>
<BR><FONT SIZE=3D2>&gt; neither maddr nor host</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; portion of RURI matches the server.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Let's say proxy at sip.company.com receives a requests like:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; sip:abc@someone-else.com;maddr=3Dproxy.com</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; .......</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Route:</FONT>
<BR><FONT SIZE=3D2>&gt; =
&lt;sip:123@yet-someone-else.com;maddr=3Dyet-yet-someone-else.com&gt;</F=
ONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; As Billy pointed out you, being the proxy, don't really want</FONT>
<BR><FONT SIZE=3D2>&gt; to pop Route header</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; blindly. I would rather</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; propose something along theses lines - it is really close to</FONT>
<BR><FONT SIZE=3D2>&gt; your 2 case (it</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; also takes care of scenario where</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Proxy has it's own outbound Proxy which may have its own</FONT>
<BR><FONT SIZE=3D2>&gt; outbound Proxy etc - if</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; you were to pop Route at</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; every hop the message would never get to the proper</FONT>
<BR><FONT SIZE=3D2>&gt; Proxies):</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Investigate RURI first:</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; 1)&nbsp;&nbsp; if maddr exist and it doesn't match your domain =
send</FONT>
<BR><FONT SIZE=3D2>&gt; message to:</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - address indicated in maddr and strip =
maddr.</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - or, if outbound Proxy is used, to =
outbound Proxy and</FONT>
<BR><FONT SIZE=3D2>&gt; preserve maddr</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - or, return 488 if unwilling/unable to =
forward the</FONT>
<BR><FONT SIZE=3D2>&gt; request (I explained my</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; reasoning for 488 in previous posting)</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; 2)&nbsp;&nbsp; if maddr exist and it matches your domain strip =
maddr</FONT>
<BR><FONT SIZE=3D2>&gt; and go to 3</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; 3)&nbsp;&nbsp; if host part of RURI doesn't match your domain =
send</FONT>
<BR><FONT SIZE=3D2>&gt; message to:</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - address indicated in host part of =
RURI and preserve</FONT>
<BR><FONT SIZE=3D2>&gt; existing RURI and</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; Route(s),</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - or, if outbound Proxy is used, to =
outbound Proxy and</FONT>
<BR><FONT SIZE=3D2>&gt; preserve existing</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; RURI and Route(s),</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; 4)&nbsp;&nbsp; if host part of RURI does match your domain pop =
first</FONT>
<BR><FONT SIZE=3D2>&gt; Route header and go</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; back to 1</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (now your RURI is whatever Route header =
contained).</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; 5)&nbsp;&nbsp; if there's no Route header do whatever you want =
(get</FONT>
<BR><FONT SIZE=3D2>&gt; contact from your</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; location/registrar server most likely) =
and go back to 1</FONT>
<BR><FONT SIZE=3D2>&gt; (now RURI is</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; whatever you got</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; from location/registrar server)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; regards, Jacek Grabiec</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; sip:jacek_grabiec@sip.3com.com</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; _______________________________________________</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; SIP mailing list</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; SIP@lists.bell-labs.com</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; <A HREF=3D"http://lists.bell-labs.com/mailman/listinfo/sip" =
TARGET=3D"_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></F=
ONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0822B.8A4A65B0--

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 19 11:50:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02061
	for <sip-archive@odin.ietf.org>; Fri, 19 Jan 2001 11:50:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 254B54433E; Fri, 19 Jan 2001 10:51:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id B5B0D44336
	for <sip@lists.bell-labs.com>; Fri, 19 Jan 2001 10:50:58 -0500 (EST)
Received: (qmail 26995 invoked by uid 500); 19 Jan 2001 15:08:01 -0000
From: David Frascone <dave@frascone.com>
To: sip@lists.bell-labs.com
Message-ID: <20010119090800.A26822@newman.frascone.com>
Mail-Followup-To: sip@lists.bell-labs.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-encrypt-payload: no
Subject: [SIP] T2 and 182 Queued
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 19 Jan 2001 09:08:00 -0600

When 182's are sent to indicate queueing, there is no mention of what happens
to T2.  I would *assume* that it needs to be reset, but it is not mentioned
in 2543bis-02.

4 seconds (the sugested default for T2) is *way* to short for a queued call.


Dave Frascone

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 19 11:54:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02162
	for <sip-archive@odin.ietf.org>; Fri, 19 Jan 2001 11:54:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9F5DD443BF; Fri, 19 Jan 2001 10:55:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id 73F80443BD
	for <sip@lists.bell-labs.com>; Fri, 19 Jan 2001 10:54:42 -0500 (EST)
Received: (qmail 29139 invoked by uid 500); 19 Jan 2001 16:58:26 -0000
From: David Frascone <dave@frascone.com>
To: sip@lists.bell-labs.com
Subject: Re: [SIP] Terminating pending calls
Message-ID: <20010119105825.N27074@newman.frascone.com>
Mail-Followup-To: sip@lists.bell-labs.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 19 Jan 2001 10:58:25 -0600

I think the draft was very clear in stating that the call needs to be ACK'ed
then BYE'd.

The far end would already have it's data stream set up, if it went through
any proxies, since it already received its ACK.

So, sending a BYE instead of an ACK doesn't really buy you any benefits, 
except to break the RFC and save a couple of packet round trips.

-Dave



On Thu, Jan 18, 2001 at 12:19:08PM +0200, Will van der Leij wrote:
> Hi,
> My apologies if this has been covered somewhere in the archives,
> I'm still scanning through them.
> 
> I have a question regarding the termination of pending INVITEs
> without the possibility of the call being set up.
> Consider sending an INVITE which gets a 200 OK response.
> The UA decides, fow whatever reason, to drop the call. To do
> this, the UA sends a BYE. The INVITE, however, needs to be
> ACKed as well. Now if the BYE and ACK follow different routes,
> then there is the possibility that the ACK arrives first and 
> the call gets set up before the BYE terminates it.
> 
> Is there anything wrong with sending the BYE after receiving
> the 200 OK for the INVITE and then only ACKing the INVITE after
> receiving the 200 OK response to the BYE? The only draw back I 
> can see here is that the server might retransmit the response 
> before it receives the BYE. Or do we send them together?
> 
> I was also wondering why we need to send an ACK if we are going to
> send a BYE for the call? Can the BYE, in such a case, not perform
> the role of the ACK as far as the server is concerned?
> 
> Regards,
> Will van der Leij
> 
> __________/\/^^^^^^\______
> W.R.van der Leij
> Azisa (Pty) Ltd.
> http://www.azisa.co.za
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.

----- End forwarded message -----

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 19 12:00:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02369
	for <sip-archive@odin.ietf.org>; Fri, 19 Jan 2001 12:00:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 05EC0443C8; Fri, 19 Jan 2001 11:01:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.azisa.co.za (mail.azisa.co.za [196.14.124.43])
	by lists.bell-labs.com (Postfix) with ESMTP id 8A5C3443BD
	for <sip@lists.bell-labs.com>; Fri, 19 Jan 2001 11:00:40 -0500 (EST)
Received: by MAIL with Internet Mail Service (5.5.2650.21)
	id <CXVXLSKF>; Fri, 19 Jan 2001 19:02:51 +0200
Message-ID: <934C10A9A64AD4119440009027E099889A2E95@MAIL>
From: Will van der Leij <wvdleij@azisa.co.za>
To: David Frascone <dave@frascone.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Terminating pending calls
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 19 Jan 2001 19:02:50 +0200

> I think the draft was very clear in stating that the call 
> needs to be ACK'ed
> then BYE'd.
> 
> The far end would already have it's data stream set up, if it 
> went through any proxies, since it already received its ACK.
> 
> So, sending a BYE instead of an ACK doesn't really buy you 
> any benefits, 
> except to break the RFC and save a couple of packet round trips.
> 
> -Dave

Hi Dave,
It is the setting up of the data stream that interests me.
If the BYE is arrives after the ACK, the call is established, 
possibly long enough for the user to be billed for a call he had
rejected. It is this scenario I'm investigating.

Will

> 
> 
> 
> On Thu, Jan 18, 2001 at 12:19:08PM +0200, Will van der Leij wrote:
> > Hi,
> > My apologies if this has been covered somewhere in the archives,
> > I'm still scanning through them.
> > 
> > I have a question regarding the termination of pending INVITEs
> > without the possibility of the call being set up.
> > Consider sending an INVITE which gets a 200 OK response.
> > The UA decides, fow whatever reason, to drop the call. To do
> > this, the UA sends a BYE. The INVITE, however, needs to be
> > ACKed as well. Now if the BYE and ACK follow different routes,
> > then there is the possibility that the ACK arrives first and 
> > the call gets set up before the BYE terminates it.
> > 
> > Is there anything wrong with sending the BYE after receiving
> > the 200 OK for the INVITE and then only ACKing the INVITE after
> > receiving the 200 OK response to the BYE? The only draw back I 
> > can see here is that the server might retransmit the response 
> > before it receives the BYE. Or do we send them together?
> > 
> > I was also wondering why we need to send an ACK if we are going to
> > send a BYE for the call? Can the BYE, in such a case, not perform
> > the role of the ACK as far as the server is concerned?
> > 
> > Regards,
> > Will van der Leij
> > 
> > __________/\/^^^^^^\______
> > W.R.van der Leij
> > Azisa (Pty) Ltd.
> > http://www.azisa.co.za
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 19 12:18:58 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02802
	for <sip-archive@odin.ietf.org>; Fri, 19 Jan 2001 12:18:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 785E2443D3; Fri, 19 Jan 2001 11:19:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id 5FE36443D1
	for <sip@lists.bell-labs.com>; Fri, 19 Jan 2001 11:18:43 -0500 (EST)
Received: (qmail 29681 invoked by uid 500); 19 Jan 2001 17:22:27 -0000
From: David Frascone <dave@frascone.com>
To: Will van der Leij <wvdleij@azisa.co.za>
Cc: David Frascone <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] Terminating pending calls
Message-ID: <20010119112226.T27074@newman.frascone.com>
Mail-Followup-To: Will van der Leij <wvdleij@azisa.co.za>,
	David Frascone <dave@frascone.com>, sip@lists.bell-labs.com
References: <934C10A9A64AD4119440009027E099889A2E95@MAIL>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <934C10A9A64AD4119440009027E099889A2E95@MAIL>; from wvdleij@azisa.co.za on Fri, Jan 19, 2001 at 07:02:50PM +0200
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 19 Jan 2001 11:22:27 -0600

On Fri, Jan 19, 2001 at 07:02:50PM +0200, Will van der Leij wrote:
> > I think the draft was very clear in stating that the call 
> > needs to be ACK'ed
> > then BYE'd.
> > 
> > The far end would already have it's data stream set up, if it 
> > went through any proxies, since it already received its ACK.
> > 
> > So, sending a BYE instead of an ACK doesn't really buy you 
> > any benefits, 
> > except to break the RFC and save a couple of packet round trips.
> > 
> > -Dave
> 
> Hi Dave,
> It is the setting up of the data stream that interests me.
> If the BYE is arrives after the ACK, the call is established, 
> possibly long enough for the user to be billed for a call he had
> rejected. It is this scenario I'm investigating.
> 

It really depends on what you're billing.  Since the caller has already
terminated, billing on the caller will be nil.  Now, the callee could be
sending data, but he could not have received any, and his sent data would
not have been received.

I think you could design a billing algorithm to handle this race condition
pretty easily.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 19 16:18:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06479
	for <sip-archive@odin.ietf.org>; Fri, 19 Jan 2001 16:18:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7695C4434D; Fri, 19 Jan 2001 15:19:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id AFF1F44336
	for <sip@lists.bell-labs.com>; Fri, 19 Jan 2001 15:18:36 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0JLITK29006;
	Fri, 19 Jan 2001 15:18:29 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: sip@lists.bell-labs.com
Cc: billy@billybiggs.com, rohan@cisco.com
Message-ID: <20010119151829.D19088@fdd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [SIP] draft-ietf-sip-handoff-00.txt
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 19 Jan 2001 15:18:29 -0600


draft-ietf-sip-handoff-00.txt is now available at
http://phonectl.sfour.com/draft-ietf-sip-handoff-00.txt 

Protocol changes since draft-ietf-handoff-00pre8.txt are...

* Refer-To changed to Handoff-To
* Additional headers made not allowed in application/sip-headers.
* more definitions including B2BUA.
* Explicitly allow provisional refer-status
* Explicitly allow transferor to send BYE before "Refer-Status"
  received without affecting HANDOFF.
* Section added to describe supervised transfer strategy.
* Section added for music-on-hold strategy
* Audio mixing in the transferee depreciated.
* HANDOFF 200 OK implicitly mutes audio unless overridden with SDP.

Cheers,
Rick



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 19 16:46:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06844
	for <sip-archive@odin.ietf.org>; Fri, 19 Jan 2001 16:46:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D00B6443C0; Fri, 19 Jan 2001 15:47:03 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 38F454435A
	for <sip@lists.bell-labs.com>; Fri, 19 Jan 2001 15:46:00 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0JLjrI30063
	for sip@lists.bell-labs.com; Fri, 19 Jan 2001 15:45:53 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: sip@lists.bell-labs.com
Subject: Re: [SIP] draft-ietf-sip-handoff-00.txt
Message-ID: <20010119154553.A9401@fdd.com>
References: <20010119151829.D19088@fdd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010119151829.D19088@fdd.com>; from siplist@fdd.com on Fri, Jan 19, 2001 at 03:18:29PM -0600
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 19 Jan 2001 15:45:53 -0600


Please forgive my mistake.  The correct name for
this draft is draft-dean-handoff-00.txt.
http://phonectl.sfour.com/draft-dean-handoff-00.txt 

--
Rick


On Fri, Jan 19, 2001 at 03:18:29PM -0600, Rick Dean wrote:
> 
> draft-ietf-sip-handoff-00.txt is now available at
> http://phonectl.sfour.com/draft-ietf-sip-handoff-00.txt 
> 
> Protocol changes since draft-ietf-handoff-00pre8.txt are...
> 
> * Refer-To changed to Handoff-To
> * Additional headers made not allowed in application/sip-headers.
> * more definitions including B2BUA.
> * Explicitly allow provisional refer-status
> * Explicitly allow transferor to send BYE before "Refer-Status"
>   received without affecting HANDOFF.
> * Section added to describe supervised transfer strategy.
> * Section added for music-on-hold strategy
> * Audio mixing in the transferee depreciated.
> * HANDOFF 200 OK implicitly mutes audio unless overridden with SDP.
> 
> Cheers,
> Rick
> 
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 19 20:20:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08774
	for <sip-archive@odin.ietf.org>; Fri, 19 Jan 2001 20:20:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3C39E4435A; Fri, 19 Jan 2001 19:21:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 7427C44336
	for <sip@lists.bell-labs.com>; Fri, 19 Jan 2001 19:20:00 -0500 (EST)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <CKD5QA0R>; Fri, 19 Jan 2001 17:19:36 -0800
Message-ID: <E79883AEA37FD411A58C00508BAC5F4B2B5C93@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Rick Dean'" <siplist@fdd.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] draft-ietf-sip-handoff-00.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0827F.0AC9D1F0"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 19 Jan 2001 17:19:31 -0800

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_01C0827F.0AC9D1F0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Rick & Billy,

I refer to the following change:

   HANDOFF is designed to proceed quickly at the end of conferencing,
   thus media mixing in the transferee is not required.

I agree that this is better than saying that the transferee MAY mix audio
but should not be expected to; however, I believe that more description is
needed of the behaviour when the transferor does _not_ place the transferee
on hold. 

I beleive that it should say: If the transferor does not place the
transferee on hold in the HANDOFF, then the voice/media connection with the
transferor should be maintained whilst the HANDOFF has not connected or
completed. If the transferor does place the transferee on hold, then the
transferee should apply/display (local or media-based) session progress
indications of the spawned INVITE to the user. In the former case, the
transferee is of course free to display or audio mix these session progress
indications whilst still in communication with the transferor.

I can think of many attended trasnfer & operator assisted calling situations
where this would be useful. You statement "HANDOFF is designed to proceed
quickly" is also ambiguous. If you actually mean that the spawned INIVTE
should proceed quickly then I think you may be unnecessarily only
considering a subset of potential applications.

I disagree with your change about leaving out the SDP in the HANDOFF or 200
OK to mean on-hold. This goes against the prevailing idea that where SDP is
possible, no SDP means no change. That is, if there is no SDP in the HANDOFF
then the transferee will remain connected with the transferor until the
HANDOFF connects or completes. [Which is IMO a good idea.]

In fact, I beleive that your HANDOFF draft goes against the
mandate/assumption that all (primary) session state should be changed
through re-INVITE exchanges. By allowing SDP in HANDOFF requests (at all)
you are violating this non-trivial property and creating potential
contentions between HANDOFF and re-INVITE transactions - whilst this is a
not unsolvable problem I do agree with the original motivation of the
mandate. 

Rick, from your postings it seems as though you "by default" wish to place
the transferee on hold and have the assumption that HANDOFF completes
quickly. Given these conditions how different then is the situation that 
- The HANDOFF may not contain SDP (thereby not violatign any state
assumptions or creating contention). Thus the transferee and transferor
remain in communication while waiting for the spawned iNVITE to connect or
complete.
- When the spawned invite connects or completes, the transferee sends a
re-INVITE with a Handoff-Status and may also place each other onhold if they
desire (or BYE).

Your motivation for allowing SDP in HANDOFF seems to be that you do not want
lots of messages or queues of pending requests, so I'll be interested to see
what you think of this suggestion (which has neither).

Regards,

Robert.

PS. I like the name HANDOFF I think it succinctly conveys the jist of what
the method does.

-- My opinions are my own and should not be taken as representing those of
Nuera Communications, Inc. --

> -----Original Message-----
> From: Rick Dean [mailto:siplist@fdd.com]
> Sent: Friday, January 19, 2001 9:46 PM
> To: sip@lists.bell-labs.com
> Subject: Re: [SIP] draft-ietf-sip-handoff-00.txt
> 
> 
> 
> Please forgive my mistake.  The correct name for
> this draft is draft-dean-handoff-00.txt.
> http://phonectl.sfour.com/draft-dean-handoff-00.txt 
> 
> --
> Rick
> 
> 
> On Fri, Jan 19, 2001 at 03:18:29PM -0600, Rick Dean wrote:
> > 
> > draft-ietf-sip-handoff-00.txt is now available at
> > http://phonectl.sfour.com/draft-ietf-sip-handoff-00.txt 
> > 
> > Protocol changes since draft-ietf-handoff-00pre8.txt are...
> > 
> > * Refer-To changed to Handoff-To
> > * Additional headers made not allowed in application/sip-headers.
> > * more definitions including B2BUA.
> > * Explicitly allow provisional refer-status
> > * Explicitly allow transferor to send BYE before "Refer-Status"
> >   received without affecting HANDOFF.
> > * Section added to describe supervised transfer strategy.
> > * Section added for music-on-hold strategy
> > * Audio mixing in the transferee depreciated.
> > * HANDOFF 200 OK implicitly mutes audio unless overridden with SDP.
> > 
> > Cheers,
> > Rick
> > 
> > 
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

------_=_NextPart_001_01C0827F.0AC9D1F0
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [SIP] draft-ietf-sip-handoff-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Rick &amp; Billy,</FONT>
</P>

<P><FONT SIZE=3D2>I refer to the following change:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; HANDOFF is designed to proceed quickly =
at the end of conferencing,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; thus media mixing in the transferee is =
not required.</FONT>
</P>

<P><FONT SIZE=3D2>I agree that this is better than saying that the =
transferee MAY mix audio but should not be expected to; however, I =
believe that more description is needed of the behaviour when the =
transferor does _not_ place the transferee on hold. </FONT></P>

<P><FONT SIZE=3D2>I beleive that it should say: If the transferor does =
not place the transferee on hold in the HANDOFF, then the voice/media =
connection with the transferor should be maintained whilst the HANDOFF =
has not connected or completed. If the transferor does place the =
transferee on hold, then the transferee should apply/display (local or =
media-based) session progress indications of the spawned INVITE to the =
user. In the former case, the transferee is of course free to display =
or audio mix these session progress indications whilst still in =
communication with the transferor.</FONT></P>

<P><FONT SIZE=3D2>I can think of many attended trasnfer &amp; operator =
assisted calling situations where this would be useful. You statement =
&quot;HANDOFF is designed to proceed quickly&quot; is also ambiguous. =
If you actually mean that the spawned INIVTE should proceed quickly =
then I think you may be unnecessarily only considering a subset of =
potential applications.</FONT></P>

<P><FONT SIZE=3D2>I disagree with your change about leaving out the SDP =
in the HANDOFF or 200 OK to mean on-hold. This goes against the =
prevailing idea that where SDP is possible, no SDP means no change. =
That is, if there is no SDP in the HANDOFF then the transferee will =
remain connected with the transferor until the HANDOFF connects or =
completes. [Which is IMO a good idea.]</FONT></P>

<P><FONT SIZE=3D2>In fact, I beleive that your HANDOFF draft goes =
against the mandate/assumption that all (primary) session state should =
be changed through re-INVITE exchanges. By allowing SDP in HANDOFF =
requests (at all) you are violating this non-trivial property and =
creating potential contentions between HANDOFF and re-INVITE =
transactions - whilst this is a not unsolvable problem I do agree with =
the original motivation of the mandate. </FONT></P>

<P><FONT SIZE=3D2>Rick, from your postings it seems as though you =
&quot;by default&quot; wish to place the transferee on hold and have =
the assumption that HANDOFF completes quickly. Given these conditions =
how different then is the situation that </FONT></P>

<P><FONT SIZE=3D2>- The HANDOFF may not contain SDP (thereby not =
violatign any state assumptions or creating contention). Thus the =
transferee and transferor remain in communication while waiting for the =
spawned iNVITE to connect or complete.</FONT></P>

<P><FONT SIZE=3D2>- When the spawned invite connects or completes, the =
transferee sends a re-INVITE with a Handoff-Status and may also place =
each other onhold if they desire (or BYE).</FONT></P>

<P><FONT SIZE=3D2>Your motivation for allowing SDP in HANDOFF seems to =
be that you do not want lots of messages or queues of pending requests, =
so I'll be interested to see what you think of this suggestion (which =
has neither).</FONT></P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

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

<P><FONT SIZE=3D2>PS. I like the name HANDOFF I think it succinctly =
conveys the jist of what the method does.</FONT>
</P>

<P><FONT SIZE=3D2>-- My opinions are my own and should not be taken as =
representing those of Nuera Communications, Inc. --</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Rick Dean [<A =
HREF=3D"mailto:siplist@fdd.com">mailto:siplist@fdd.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, January 19, 2001 9:46 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: sip@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [SIP] =
draft-ietf-sip-handoff-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Please forgive my mistake.&nbsp; The correct =
name for</FONT>
<BR><FONT SIZE=3D2>&gt; this draft is draft-dean-handoff-00.txt.</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://phonectl.sfour.com/draft-dean-handoff-00.txt" =
TARGET=3D"_blank">http://phonectl.sfour.com/draft-dean-handoff-00.txt</A=
> </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; Rick</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Fri, Jan 19, 2001 at 03:18:29PM -0600, Rick =
Dean wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; draft-ietf-sip-handoff-00.txt is now =
available at</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A =
HREF=3D"http://phonectl.sfour.com/draft-ietf-sip-handoff-00.txt" =
TARGET=3D"_blank">http://phonectl.sfour.com/draft-ietf-sip-handoff-00.tx=
t</A> </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Protocol changes since =
draft-ietf-handoff-00pre8.txt are...</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; * Refer-To changed to Handoff-To</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; * Additional headers made not allowed in =
application/sip-headers.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; * more definitions including B2BUA.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; * Explicitly allow provisional =
refer-status</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; * Explicitly allow transferor to send BYE =
before &quot;Refer-Status&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp; received without affecting =
HANDOFF.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; * Section added to describe supervised =
transfer strategy.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; * Section added for music-on-hold =
strategy</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; * Audio mixing in the transferee =
depreciated.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; * HANDOFF 200 OK implicitly mutes audio =
unless overridden with SDP.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cheers,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Rick</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This list is for continuing development of =
the SIP protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The sip-implementer's list is the place to =
discuss implementation,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; and to receive advice on understanding =
existing sip.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To subscribe to it, send mail to =
majordomo@cs.columbia.edu with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;subscribe sip-implementors&quot; in =
the body.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; This list is for continuing development of the =
SIP protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; The sip-implementer's list is the place to =
discuss implementation,</FONT>
<BR><FONT SIZE=3D2>&gt; and to receive advice on understanding existing =
sip.</FONT>
<BR><FONT SIZE=3D2>&gt; To subscribe to it, send mail to =
majordomo@cs.columbia.edu with</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;subscribe sip-implementors&quot; in the =
body.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0827F.0AC9D1F0--

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 20 01:26:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15374
	for <sip-archive@odin.ietf.org>; Sat, 20 Jan 2001 01:26:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4826B4433A; Sat, 20 Jan 2001 00:27:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cybertron.div8.net (HSE-Kitchener-ppp320767.sympatico.ca [64.231.176.14])
	by lists.bell-labs.com (Postfix) with ESMTP id BFC9A44336
	for <sip@lists.bell-labs.com>; Sat, 20 Jan 2001 00:26:53 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m14JrVl-003EreC@cybertron.div8.net> (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Sat, 20 Jan 2001 01:28:29 -0500 (EST) 
From: Billy Biggs <billy@billybiggs.com>
To: Robert Fairlie-Cuninghame <rfairlie@nuera.com>
Cc: Rick Dean <siplist@fdd.com>, SIP List <sip@lists.bell-labs.com>
Subject: Re: [SIP] draft-ietf-sip-handoff-00.txt
Message-ID: <20010120012829.A959@div8.net>
References: <E79883AEA37FD411A58C00508BAC5F4B2B5C93@exchange1.nuera.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <E79883AEA37FD411A58C00508BAC5F4B2B5C93@exchange1.nuera.com>; from rfairlie@nuera.com on Fri, Jan 19, 2001 at 05:19:31PM -0800
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 20 Jan 2001 01:28:29 -0500

  My opinions may differ slightly from Rick's.  You discuss two of our
proposed behaviors:

  1. "HANDOFF is designed to proceed quickly at the end of conferencing,
      thus media mixing in the transferee is not required."

  2. "If the HANDOFF request or response does not include SDP
      then a media description of no media is implied. [...] The
      anticipated use of transferor-transferee media after HANDOFF is
      minimal, so default hold simplifies most messages."

  These behaviors are to optimize for handoff of a 3-way call.  We
strongly believe that this is the most important problem to solve.
3-way call handoff involves the mixer leaving the call, connecting the
two remote endpoints.  In the case of failure, the transferee
re-INVITEs, asking the transferror to continue the original 3-way call.

      A       B                  A ----- B
        \   /         ====>
          C                          C

  The handoff should be instantaneous.  When C gets a 200-class response
to the HANDOFF, the call disappears from C's UI (suspended).  When B
receives the INVITE, it should accept immediately without sending a 180.
If the call between A and B fails, A re-INVITEs C with a Handoff-Status.
C will send back a 180 Ringing to the re-INVITE as the phone asks C's
user to resume the 3-way call.

  In this situation, the media should be muted immediately when the
HANDOFF is accepted, and dependant on whether the HANDOFF is accepted.
This is why we need the HANDOFF transaction to affect the session
description.  There is no reason for the transferee to mix, since the
conferencing stage was already performed by C who is leaving.

  To perform an attended transfer you also need to specify some headers
to copy into the spawned INVITE.  I want these in the body, not the URI.
Defaulting to hold SDP avoids forcing implementors to deal with
receiving multipart bodies.


  The reason to allow retaining the pre-HANDOFF session is to accomodate
different styles of unattended transfer.  I believe it is extremely
important that the transferor-transferee session only remains active if
both parties _explicitly_ agree to it.

  To achieve this, the session only survives when both the transferor
and transferee specify a non-hold session description.  No
Handoff-Status is ever sent in the call-leg as it is now unnecessary (we
know we are performing unattended transfer, and we know the far-end
still wants to talk to us).  The transferee is free to mix in the audio
from the spawned INVITE.  I plan to clarify this in the draft.


  The only issue is whether a blank HANDOFF implies a hold (no media)
session description.  I believe the optimization is useful and cheap.


> I beleive that it should say: If the transferor does not place the
> transferee on hold in the HANDOFF, then the voice/media connection
> with the transferor should be maintained whilst the HANDOFF has not
> connected or completed.

  If the connection stays up, it shouldn't be tied to the spawned call.
This is why no Handoff-Status messages are sent if the session remains
active (not in the current draft, but I intend to change it).  Of
course, the transferee can just send a BYE when the new call connects,
if it wants this behavior.

  I don't want a blank HANDOFF to keep the connection active, since I
want to perform attended transfer without requiring multipart bodies.

> I disagree with your change about leaving out the SDP in the HANDOFF
> or 200 OK to mean on-hold. This goes against the prevailing idea that
> where SDP is possible, no SDP means no change.

  HANDOFF is a new method.  I think this is a reasonable thing to
specify.

> In fact, I beleive that your HANDOFF draft goes against the
> mandate/assumption that all (primary) session state should be changed
> through re-INVITE exchanges.

  The audio must be muted immediately when the HANDOFF is accepted, and
dependant on whether the HANDOFF is accepted.  Since SIP is for
sessions, I find it hard to imagine that extensions should not modify
the session. :)

  PRACK is another extension which allows session descriptions...

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sun Jan 21 20:24:55 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12340
	for <sip-archive@odin.ietf.org>; Sun, 21 Jan 2001 20:24:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 09FDE44337; Sun, 21 Jan 2001 19:25:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 06E7E44336
	for <sip@lists.bell-labs.com>; Sun, 21 Jan 2001 19:24:50 -0500 (EST)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <CKD5QB27>; Sun, 21 Jan 2001 17:24:15 -0800
Message-ID: <E79883AEA37FD411A58C00508BAC5F4B2B5C97@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'Billy Biggs'" <billy@billybiggs.com>
Cc: Rick Dean <siplist@fdd.com>, SIP List <sip@lists.bell-labs.com>
Subject: RE: [SIP] draft-ietf-sip-handoff-00.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C08412.083FCA90"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 21 Jan 2001 17:24:14 -0800

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_01C08412.083FCA90
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Billy,
> 
>   My opinions may differ slightly from Rick's.  You discuss two of our
> proposed behaviors:
> 
>   1. "HANDOFF is designed to proceed quickly at the end of 
> conferencing,
>       thus media mixing in the transferee is not required."
> 
>   2. "If the HANDOFF request or response does not include SDP
>       then a media description of no media is implied. [...] The
>       anticipated use of transferor-transferee media after HANDOFF is
>       minimal, so default hold simplifies most messages."
> 

Thansk for the reply. I'm surprised more people are weighting into the
discussion.

>   These behaviors are to optimize for handoff of a 3-way call.  We
> strongly believe that this is the most important problem to solve.
> 3-way call handoff involves the mixer leaving the call, connecting the
> two remote endpoints.  In the case of failure, the transferee
> re-INVITEs, asking the transferror to continue the original 
> 3-way call.
> 
>       A       B                  A ----- B
>         \   /         ====>
>           C                          C

Right. You are optimizing for a particular scenario so that this scenario
does not need multiple queued requests or multipart. Thought still needs to
be given to other ways in which HANDOFF can be used.

>   The handoff should be instantaneous.  When C gets a 
> 200-class response
> to the HANDOFF, the call disappears from C's UI (suspended).  
... 
>   In this situation, the media should be muted immediately when the
> HANDOFF is accepted, and dependant on whether the HANDOFF is accepted.
> This is why we need the HANDOFF transaction to affect the session
> description.  There is no reason for the transferee to mix, since the
> conferencing stage was already performed by C who is leaving.
...
>   The reason to allow retaining the pre-HANDOFF session is to 
> accomodate
> different styles of unattended transfer.  I believe it is extremely
> important that the transferor-transferee session only remains 
> active if
> both parties _explicitly_ agree to it.

I don't see how this is at odds with what I was suggesting. 

Additionally, in your application subspace the spawned INVITE completes
quickly ... so why does it matter if the initial call leg is muted before
you receive or when you receive a 200 OK response (since the time difference
should be very small any any case). 

The transferee either has three options on receiving the 200 OK to the
spawned INVITE:
	- send re-INVITE with Handoff-Status and held-media.
	- send re-INVITE with Handoff-Status and unheld-media (in which case
the transferee shoudl probably support mix - but remember it is the
transferee's choice to send this).
	- send BYE with Handoff-Status.

In the second case, if the transferee does not want to maintain the original
media session in an unheld state, then it would place a held SDP in the
200OK of the re-INVITE. Thus we have your condition. Simple. 

This approach also furthers your motivation that the HANDOFF does not
"control" the original session.

> 
>   If the connection stays up, it shouldn't be tied to the 
> spawned call.
> This is why no Handoff-Status messages are sent if the session remains
> active (not in the current draft, but I intend to change it).  Of
> course, the transferee can just send a BYE when the new call connects,
> if it wants this behavior.
> 

Exactly but if the session remains active then it should be mixed to the
user right? Otherwise it is placed on hold or released (by either party).
Regardless, it needs to be defined.

>   I don't want a blank HANDOFF to keep the connection active, since I
> want to perform attended transfer without requiring multipart bodies.

Agreed. You want this to be as simple yet flexible as possible. No SDP means
not multipart.

> > I disagree with your change about leaving out the SDP in the HANDOFF
> > or 200 OK to mean on-hold. This goes against the prevailing 
> idea that
> > where SDP is possible, no SDP means no change.
> 
>   HANDOFF is a new method.  I think this is a reasonable thing to
> specify.
...
>   PRACK is another extension which allows session descriptions...

I don't agree. Handling the glare/contention resolution adds a lot of hidden
complexity to the implementation. This probably means people will not bother
addressing the problem (especially since the current glare resolution is
pretty broken anyway). PRACK is special method that excutes under an INVITE
transaction and remember that it is never in contention with that request,
right. I simply don't think that HANDOFF needs to do this.
 
>   The audio must be muted immediately when the HANDOFF is 
> accepted, and
> dependant on whether the HANDOFF is accepted.  Since SIP is for
> sessions, I find it hard to imagine that extensions should not modify
> the session. :)
> 

Why? Please give your reasoning behind why audio muting must be performed
when the HANDOFF is accepted (rather than when the spawned INVITE is
accepted). Exactly, SIP is for modifying sessions - that's what its for. If
you must for whatever reason mute the audio when you send the HANDOFF
(rather than when the spawned re-INVITE is accepted) then send a re-INVITE
(with held SDP) before you send the HANDOFF.

Here are a few scenarios:
-If the transferor doesn't care about the result of the call then it can
simply send a BYE after the HANDOFF 200 Ok is received (trivial case). 
-In the case where the HANDOFF completes quickly it doesn't matter if the
hold/BYE occurs before or after the spawned INVITE connects; 
-If the spawned INVITE takes some time to connect the operator will probably
want to say "Hang on, I'm having some problem ..." to the transferee? Under
your assumptions the spawned INVITE completes quickly so this is obviously
an error condition (in your model). [So not holding when receiving the
HANDOFF is the easiest action to achieve this.]

If the system must be able to work with plain-vanilla SIP clients, the
transferor needs someway of identifying whether the target supports
Replaces; otherwise the transferor will have to default back to B2BUA
transfers mode. The draft should address this.

If the transferor decides it wants to CANCEL the spawned INVITE (eg because
it is not connecting quickly or probperly), can it put a ?method=CANCEL in
the Handoff header of a second HANDOFF message?

Cheers,

Robert.

-- My opinions are my own and should not be taken as representing those of
Nuera Communications, Inc. -- 

------_=_NextPart_001_01C08412.083FCA90
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [SIP] draft-ietf-sip-handoff-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi Billy,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; My opinions may differ slightly =
from Rick's.&nbsp; You discuss two of our</FONT>
<BR><FONT SIZE=3D2>&gt; proposed behaviors:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; 1. &quot;HANDOFF is designed to =
proceed quickly at the end of </FONT>
<BR><FONT SIZE=3D2>&gt; conferencing,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; thus media =
mixing in the transferee is not required.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; 2. &quot;If the HANDOFF request or =
response does not include SDP</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; then a =
media description of no media is implied. [...] The</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; anticipated =
use of transferor-transferee media after HANDOFF is</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; minimal, so =
default hold simplifies most messages.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>Thansk for the reply. I'm surprised more people are =
weighting into the discussion.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp; These behaviors are to optimize for =
handoff of a 3-way call.&nbsp; We</FONT>
<BR><FONT SIZE=3D2>&gt; strongly believe that this is the most =
important problem to solve.</FONT>
<BR><FONT SIZE=3D2>&gt; 3-way call handoff involves the mixer leaving =
the call, connecting the</FONT>
<BR><FONT SIZE=3D2>&gt; two remote endpoints.&nbsp; In the case of =
failure, the transferee</FONT>
<BR><FONT SIZE=3D2>&gt; re-INVITEs, asking the transferror to continue =
the original </FONT>
<BR><FONT SIZE=3D2>&gt; 3-way call.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A ----- B</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
\&nbsp;&nbsp; /&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
=3D=3D=3D=3D&gt;</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; =
C&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; C</FONT>
</P>

<P><FONT SIZE=3D2>Right. You are optimizing for a particular scenario =
so that this scenario does not need multiple queued requests or =
multipart. Thought still needs to be given to other ways in which =
HANDOFF can be used.</FONT></P>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp; The handoff should be =
instantaneous.&nbsp; When C gets a </FONT>
<BR><FONT SIZE=3D2>&gt; 200-class response</FONT>
<BR><FONT SIZE=3D2>&gt; to the HANDOFF, the call disappears from C's UI =
(suspended).&nbsp; </FONT>
<BR><FONT SIZE=3D2>... </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; In this situation, the media should =
be muted immediately when the</FONT>
<BR><FONT SIZE=3D2>&gt; HANDOFF is accepted, and dependant on whether =
the HANDOFF is accepted.</FONT>
<BR><FONT SIZE=3D2>&gt; This is why we need the HANDOFF transaction to =
affect the session</FONT>
<BR><FONT SIZE=3D2>&gt; description.&nbsp; There is no reason for the =
transferee to mix, since the</FONT>
<BR><FONT SIZE=3D2>&gt; conferencing stage was already performed by C =
who is leaving.</FONT>
<BR><FONT SIZE=3D2>...</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; The reason to allow retaining the =
pre-HANDOFF session is to </FONT>
<BR><FONT SIZE=3D2>&gt; accomodate</FONT>
<BR><FONT SIZE=3D2>&gt; different styles of unattended transfer.&nbsp; =
I believe it is extremely</FONT>
<BR><FONT SIZE=3D2>&gt; important that the transferor-transferee =
session only remains </FONT>
<BR><FONT SIZE=3D2>&gt; active if</FONT>
<BR><FONT SIZE=3D2>&gt; both parties _explicitly_ agree to it.</FONT>
</P>

<P><FONT SIZE=3D2>I don't see how this is at odds with what I was =
suggesting. </FONT>
</P>

<P><FONT SIZE=3D2>Additionally, in your application subspace the =
spawned INVITE completes quickly ... so why does it matter if the =
initial call leg is muted before you receive or when you receive a 200 =
OK response (since the time difference should be very small any any =
case). </FONT></P>

<P><FONT SIZE=3D2>The transferee either has three options on receiving =
the 200 OK to the spawned INVITE:</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>- send =
re-INVITE with Handoff-Status and held-media.</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>- send =
re-INVITE with Handoff-Status and unheld-media (in which case the =
transferee shoudl probably support mix - but remember it is the =
transferee's choice to send this).</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>- send BYE =
with Handoff-Status.</FONT>
</P>

<P><FONT SIZE=3D2>In the second case, if the transferee does not want =
to maintain the original media session in an unheld state, then it =
would place a held SDP in the 200OK of the re-INVITE. Thus we have your =
condition. Simple. </FONT></P>

<P><FONT SIZE=3D2>This approach also furthers your motivation that the =
HANDOFF does not &quot;control&quot; the original session.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; If the connection stays up, it =
shouldn't be tied to the </FONT>
<BR><FONT SIZE=3D2>&gt; spawned call.</FONT>
<BR><FONT SIZE=3D2>&gt; This is why no Handoff-Status messages are sent =
if the session remains</FONT>
<BR><FONT SIZE=3D2>&gt; active (not in the current draft, but I intend =
to change it).&nbsp; Of</FONT>
<BR><FONT SIZE=3D2>&gt; course, the transferee can just send a BYE when =
the new call connects,</FONT>
<BR><FONT SIZE=3D2>&gt; if it wants this behavior.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>Exactly but if the session remains active then it =
should be mixed to the user right? Otherwise it is placed on hold or =
released (by either party). Regardless, it needs to be =
defined.</FONT></P>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp; I don't want a blank HANDOFF to keep =
the connection active, since I</FONT>
<BR><FONT SIZE=3D2>&gt; want to perform attended transfer without =
requiring multipart bodies.</FONT>
</P>

<P><FONT SIZE=3D2>Agreed. You want this to be as simple yet flexible as =
possible. No SDP means not multipart.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt; I disagree with your change about leaving =
out the SDP in the HANDOFF</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; or 200 OK to mean on-hold. This goes =
against the prevailing </FONT>
<BR><FONT SIZE=3D2>&gt; idea that</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; where SDP is possible, no SDP means no =
change.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; HANDOFF is a new method.&nbsp; I =
think this is a reasonable thing to</FONT>
<BR><FONT SIZE=3D2>&gt; specify.</FONT>
<BR><FONT SIZE=3D2>...</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; PRACK is another extension which =
allows session descriptions...</FONT>
</P>

<P><FONT SIZE=3D2>I don't agree. Handling the glare/contention =
resolution adds a lot of hidden complexity to the implementation. This =
probably means people will not bother addressing the problem =
(especially since the current glare resolution is pretty broken =
anyway). PRACK is special method that excutes under an INVITE =
transaction and remember that it is never in contention with that =
request, right. I simply don't think that HANDOFF needs to do =
this.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; The audio must be muted immediately =
when the HANDOFF is </FONT>
<BR><FONT SIZE=3D2>&gt; accepted, and</FONT>
<BR><FONT SIZE=3D2>&gt; dependant on whether the HANDOFF is =
accepted.&nbsp; Since SIP is for</FONT>
<BR><FONT SIZE=3D2>&gt; sessions, I find it hard to imagine that =
extensions should not modify</FONT>
<BR><FONT SIZE=3D2>&gt; the session. :)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>Why? Please give your reasoning behind why audio =
muting must be performed when the HANDOFF is accepted (rather than when =
the spawned INVITE is accepted). Exactly, SIP is for modifying sessions =
- that's what its for. If you must for whatever reason mute the audio =
when you send the HANDOFF (rather than when the spawned re-INVITE is =
accepted) then send a re-INVITE (with held SDP) before you send the =
HANDOFF.</FONT></P>

<P><FONT SIZE=3D2>Here are a few scenarios:</FONT>
<BR><FONT SIZE=3D2>-If the transferor doesn't care about the result of =
the call then it can simply send a BYE after the HANDOFF 200 Ok is =
received (trivial case). </FONT></P>

<P><FONT SIZE=3D2>-In the case where the HANDOFF completes quickly it =
doesn't matter if the hold/BYE occurs before or after the spawned =
INVITE connects; </FONT></P>

<P><FONT SIZE=3D2>-If the spawned INVITE takes some time to connect the =
operator will probably want to say &quot;Hang on, I'm having some =
problem ...&quot; to the transferee? Under your assumptions the spawned =
INVITE completes quickly so this is obviously an error condition (in =
your model). [So not holding when receiving the HANDOFF is the easiest =
action to achieve this.]</FONT></P>

<P><FONT SIZE=3D2>If the system must be able to work with plain-vanilla =
SIP clients, the transferor needs someway of identifying whether the =
target supports Replaces; otherwise the transferor will have to default =
back to B2BUA transfers mode. The draft should address this.</FONT></P>

<P><FONT SIZE=3D2>If the transferor decides it wants to CANCEL the =
spawned INVITE (eg because it is not connecting quickly or probperly), =
can it put a ?method=3DCANCEL in the Handoff header of a second HANDOFF =
message?</FONT></P>

<P><FONT SIZE=3D2>Cheers,</FONT>
</P>

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

<P><FONT SIZE=3D2>-- My opinions are my own and should not be taken as =
representing those of Nuera Communications, Inc. -- </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08412.083FCA90--

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sun Jan 21 23:13:53 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15466
	for <sip-archive@odin.ietf.org>; Sun, 21 Jan 2001 23:13:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 599D944339; Sun, 21 Jan 2001 22:14:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cybertron.div8.net (HSE-Kitchener-ppp321190.sympatico.ca [64.231.177.183])
	by lists.bell-labs.com (Postfix) with ESMTP id 32B4644336
	for <sip@lists.bell-labs.com>; Sun, 21 Jan 2001 22:13:07 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m14KYNU-003EreC@cybertron.div8.net> (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Sun, 21 Jan 2001 23:14:48 -0500 (EST) 
From: Billy Biggs <billy@billybiggs.com>
To: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
Cc: Rick Dean <siplist@fdd.com>, SIP List <sip@lists.bell-labs.com>
Subject: Re: [SIP] draft-ietf-sip-handoff-00.txt
Message-ID: <20010121231448.A592@div8.net>
References: <E79883AEA37FD411A58C00508BAC5F4B2B5C97@exchange1.nuera.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <E79883AEA37FD411A58C00508BAC5F4B2B5C97@exchange1.nuera.com>; from rfairlie@nuera.com on Sun, Jan 21, 2001 at 05:24:14PM -0800
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 21 Jan 2001 23:14:48 -0500

  I'll try and add more text about the reasons for not requiring the
transferee to ever perform mixing.

  You don't want the HANDOFF transaction affect the session description
at all, and to instead always transmit these via re-INVITEs.  The
problem is that this creates message queues, since the transferor must
first put the transferee on hold, then send the HANDOFF.

  I expect that the most common implementation of blind (unattended)
transfer with recovery will be:

  1.  HANDOFF (hold) sent and accepted.
  2.  Call disappears from transferor's UI.
  3.  Time passes
  4.  re-INVITE arrives, Handoff-Status: 486 Busy, (non-hold SDP)
  5.  Transferor sends 180 Ringing and the phone rings.
  6.  Transferor picks up and old call resumes.

  Anyways, I will think about this issue and try to clarify the draft.

> If the system must be able to work with plain-vanilla SIP clients, the
> transferor needs someway of identifying whether the target supports
> Replaces; otherwise the transferor will have to default back to B2BUA
> transfers mode. The draft should address this.

  This is explained in the Replaces draft.  We should merge the two.

> If the transferor decides it wants to CANCEL the spawned INVITE (eg
> because it is not connecting quickly or probperly), can it put a
> ?method=CANCEL in the Handoff header of a second HANDOFF message?

  No.

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 22 04:14:54 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00785
	for <sip-archive@odin.ietf.org>; Mon, 22 Jan 2001 04:14:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9360E4433E; Mon, 22 Jan 2001 03:15:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 0126344336
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 03:14:42 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0M9DvU20279;
	Mon, 22 Jan 2001 03:13:57 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] draft-ietf-sip-handoff-00.txt
Message-ID: <20010122031236.A17469@fdd.com>
References: <E79883AEA37FD411A58C00508BAC5F4B2B5C93@exchange1.nuera.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <E79883AEA37FD411A58C00508BAC5F4B2B5C93@exchange1.nuera.com>; from rfairlie@nuera.com on Fri, Jan 19, 2001 at 05:19:31PM -0800
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 22 Jan 2001 03:12:36 -0600


Robert,

If you are looking to me for defending non-mute
SDP in a HANDOFF, you are asking the wrong guy.
I can build everything I need without it.  

I am lazy, so I am trying to keep HANDOFF simple.
Even our limited scope handoff is unbelievably
complex.

Implying mute on HANDOFF without SDP lets the 
simplest implementations have the simplest messages.
It is also a good suggestion for implementors.

I have said before that mixing audio in the
transferee is a recipe for pain.   Besides
being a security, syntaxtic, and privacy nitemare, 
it works better with audio-free B2BUAs who 
intercept the transferee's role.  

Billy made some good arguments that continued 
transferer-transferee audio should be moved into 
a non-HANDOFF draft.  I am starting to agree more.


On Fri, Jan 19, 2001 at 05:19:31PM -0800, Fairlie-Cuninghame, Robert wrote:
> Hi Rick & Billy,
> 
> I refer to the following change:
> 
>    HANDOFF is designed to proceed quickly at the end of conferencing,
>    thus media mixing in the transferee is not required.
> 
> I agree that this is better than saying that the transferee MAY mix audio
> but should not be expected to; however, I believe that more description is
> needed of the behaviour when the transferor does _not_ place the transferee
> on hold. 
> 
> I beleive that it should say: If the transferor does not place the
> transferee on hold in the HANDOFF, then the voice/media connection with the
> transferor should be maintained whilst the HANDOFF has not connected or
> completed. If the transferor does place the transferee on hold, then the
> transferee should apply/display (local or media-based) session progress
> indications of the spawned INVITE to the user. In the former case, the
> transferee is of course free to display or audio mix these session progress
> indications whilst still in communication with the transferor.
> 
> I can think of many attended trasnfer & operator assisted calling situations
> where this would be useful. You statement "HANDOFF is designed to proceed
> quickly" is also ambiguous. If you actually mean that the spawned INIVTE
> should proceed quickly then I think you may be unnecessarily only
> considering a subset of potential applications.

Thanks. Sorry. We mean the HANDOFF transaction should proceed
quickly.  As you noted, handoff-status may frequently take some time.

> 
> I disagree with your change about leaving out the SDP in the HANDOFF or 200
> OK to mean on-hold. This goes against the prevailing idea that where SDP is
> possible, no SDP means no change. That is, if there is no SDP in the HANDOFF
> then the transferee will remain connected with the transferor until the
> HANDOFF connects or completes. [Which is IMO a good idea.]
> 
> In fact, I beleive that your HANDOFF draft goes against the
> mandate/assumption that all (primary) session state should be changed
> through re-INVITE exchanges. By allowing SDP in HANDOFF requests (at all)
> you are violating this non-trivial property and creating potential
> contentions between HANDOFF and re-INVITE transactions - whilst this is a
> not unsolvable problem I do agree with the original motivation of the
> mandate. 

How can a re-INVITE race with a HANDOFF traveling the same
direction in the same call-leg?  They can't overlap right?
BTW, this non-overlap (and a little packet loss) adds nasty 
complexity for phones whos humans get spaztic on the hold key, 
but is better than the alternative.  Was this your point?

Protocol beauty caries no weight with me in the face of simpler
code.  If the transferee doesn't mix audio, the current draft
is easiest.  Our real diagreement is transferee mixing.

Please ask your DSP people, "A proposal allows SIP phones to have
supervised transfer, but they gateways never have to mix audio.  Do you 
like it?"

> 
> Rick, from your postings it seems as though you "by default" wish to place
> the transferee on hold and have the assumption that HANDOFF completes
> quickly. Given these conditions how different then is the situation that 
> - The HANDOFF may not contain SDP (thereby not violatign any state
> assumptions or creating contention). Thus the transferee and transferor
> remain in communication while waiting for the spawned iNVITE to connect or
> complete.

Yeah, if you can eliminate early media.  :-)  Otherwise, no.

If the transferor is not done listening to the transferee, he
should not send the HANDOFF yet.

I can't see switching the mixer in the middle of the conference.
Are you going to have a switch-mixer-to-far-end key?  No
idiot end user of ours would understand this.  So you are
sending the HANDOFF at the beginning of the conference?
This should be different method.... or something.

> - When the spawned invite connects or completes, the transferee sends a
> re-INVITE with a Handoff-Status and may also place each other onhold if they
> desire (or BYE).
> 
> Your motivation for allowing SDP in HANDOFF seems to be that you do not want
> lots of messages or queues of pending requests, so I'll be interested to see
> what you think of this suggestion (which has neither).
> 
> Regards,
> 
> Robert.
> 
> PS. I like the name HANDOFF I think it succinctly conveys the jist of what
> the method does.

Thanks.  The method name thread with Pat Calhoun was resolved
off the list.

--
Rick
rick_dean@3com.com

> 
> -- My opinions are my own and should not be taken as representing those of
> Nuera Communications, Inc. --
> 
> > -----Original Message-----
> > From: Rick Dean [mailto:siplist@fdd.com]
> > Sent: Friday, January 19, 2001 9:46 PM
> > To: sip@lists.bell-labs.com
> > Subject: Re: [SIP] draft-ietf-sip-handoff-00.txt
> > 
> > 
> > 
> > Please forgive my mistake.  The correct name for
> > this draft is draft-dean-handoff-00.txt.
> > http://phonectl.sfour.com/draft-dean-handoff-00.txt 
> > 
> > --
> > Rick
> > 
> > 
> > On Fri, Jan 19, 2001 at 03:18:29PM -0600, Rick Dean wrote:
> > > 
> > > draft-ietf-sip-handoff-00.txt is now available at
> > > http://phonectl.sfour.com/draft-ietf-sip-handoff-00.txt 
> > > 
> > > Protocol changes since draft-ietf-handoff-00pre8.txt are...
> > > 
> > > * Refer-To changed to Handoff-To
> > > * Additional headers made not allowed in application/sip-headers.
> > > * more definitions including B2BUA.
> > > * Explicitly allow provisional refer-status
> > > * Explicitly allow transferor to send BYE before "Refer-Status"
> > >   received without affecting HANDOFF.
> > > * Section added to describe supervised transfer strategy.
> > > * Section added for music-on-hold strategy
> > > * Audio mixing in the transferee depreciated.
> > > * HANDOFF 200 OK implicitly mutes audio unless overridden with SDP.
> > > 
> > > Cheers,
> > > Rick
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementer's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > "subscribe sip-implementors" in the body.
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> > 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 22 04:42:52 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00971
	for <sip-archive@odin.ietf.org>; Mon, 22 Jan 2001 04:42:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8CB844434A; Mon, 22 Jan 2001 03:43:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by lists.bell-labs.com (Postfix) with ESMTP id 7376D44344
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 03:42:19 -0500 (EST)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id CAA07186 for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 02:42:06 -0700 (MST)]
Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id CAA02217 for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 02:42:04 -0700 (MST)]
Received: from email.mot.com (pcwks120.miel.mot.com [217.1.129.146])
	by miel.mot.com (8.9.3/8.9.3) with ESMTP id PAA27007
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 15:17:51 +0530 (IST)
Message-ID: <3A6C0237.7F6C2B1A@email.mot.com>
From: Gaurav Taneja <A15835@email.mot.com>
Organization: Motorola India Electronics Ltd.
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: SIP WG Mailing List <sip@lists.bell-labs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] DNS SRV records
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 22 Jan 2001 15:19:43 +0530
Content-Transfer-Encoding: 7bit

What are DNS SRV records and how and when are they used by SIP proxy
servers?

-Gaurav


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 22 11:50:53 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08499
	for <sip-archive@odin.ietf.org>; Mon, 22 Jan 2001 11:50:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 83ADD44341; Mon, 22 Jan 2001 10:51:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 65FB544336
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 10:50:17 -0500 (EST)
Received: from rtp-xdm1.cisco.com (rtp-xdm1.cisco.com [64.102.17.80])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA14929;
	Mon, 22 Jan 2001 08:50:15 -0800 (PST)
Received: from cisco.com (localhost [127.0.0.1]) by rtp-xdm1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA16119; Mon, 22 Jan 2001 11:50:03 -0500 (EST)
Message-ID: <3A6C64BA.BCB4294B@cisco.com>
From: Sudipto Mukherjee <sudiptom@cisco.com>
Organization: Cisco
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Gaurav Taneja <A15835@email.mot.com>
Cc: SIP WG Mailing List <sip@lists.bell-labs.com>
Subject: Re: [SIP] DNS SRV records
References: <3A6C0237.7F6C2B1A@email.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 22 Jan 2001 11:50:02 -0500
Content-Transfer-Encoding: 7bit

DNS SRV record allows devices to search for a service (e.g. sip)
in a specific domain. It allows load sharing/redundancy across
servers providing this service.

Sec 1.4.2 of RFC2543bis(-02) draft addresses your second question.
- Sudipto

Gaurav Taneja wrote:
> 
> What are DNS SRV records and how and when are they used by SIP proxy
> servers?
> 
> -Gaurav
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.

-- 

---------------------------------------------------------------------------
Sudipto Mukherjee
Cisco Systems, Inc             sudiptom@cisco.com 
  
--------------------------------------------------------------------------

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 22 11:55:00 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08605
	for <sip-archive@odin.ietf.org>; Mon, 22 Jan 2001 11:54:59 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2A9FE44355; Mon, 22 Jan 2001 10:55:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by lists.bell-labs.com (Postfix) with ESMTP id E382444353
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 10:54:10 -0500 (EST)
Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16])
	by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA17026;
	Mon, 22 Jan 2001 11:53:36 -0500 (EST)
Received: from cisco.com (rtp-ptdxdm1.cisco.com [64.102.17.217])
	by dingdong.cisco.com (Mirapoint)
	with ESMTP id AAL14771 (AUTH byerly);
	Mon, 22 Jan 2001 11:53:55 -0500 (EST)
Message-ID: <3A6C65A1.2E25E09C@cisco.com>
From: Bryan Byerly <byerly@cisco.com>
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Cc: byerly@cisco.com
Content-Type: multipart/alternative;
 boundary="------------1A5D0555CFDCFCE752C1B2D6"
Subject: [SIP] Announcements in SIP
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 22 Jan 2001 11:53:54 -0500


--------------1A5D0555CFDCFCE752C1B2D6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi guys,

I'd like to solicit ideas/consensus w/r/t announcements in SIP.

For this thread of discussion, we're talking about announcements which
are played when an error occurred during call setup.  For instance, on
404, a message could be played "The URL you have dialed B...O...B. is
not in service, please check the URL or dial the operator for
assistance".

There are at least two desired behaviors w/r/t annoucements:
Desired behavior 1: There should be a mechanism so that local
annoucements override network annoucements.
Desired behavior 2: There should be a mechanism so that announcements
are not billable.

Like call forwarding features in SIP, there are implementable solutions
to play annoucements using user agents or proxies.

In the diagrams below, A, B, and C are user agents, Po is an originating
proxy and Pt is a terminating proxy.

User agent: Event based local announcement
A                 Po             Pt
|                  |              |
|--INV Bob@B------>|              |
|                  |              |
|<-404-------------|              |
|                  |              |
A generates
local audio
indicating
"The URL you have dialed B...O...B is not in service, please check the
 URL or dial the operator for assistance."


Proxy: Event based call diversion (recursive)
A                  Po             Pt        Announcement
                                              Server
|                  |              |             |
|--INV Bob@B------>|              |             |
|                  |--INV Bob@B-->|             |
|                  |<-404---------|             |
|            proxy implements     |             |
|            call forward on 404  |             |
|                  |--INV AnnServer------------>|
|                  |  Diversion: Bob@B          |
|                  |              |             |
|<-200------------------------------------------|
|<==="The URL you have dialed B...O...B is not==|
|     in service, please check the URL or dial  |
|     the operator for assistance"


Both approaches are viable and there are advantages/disadvantages to
each.  If all user agents supported local generation of announcements,
then an event based call diversion solution may not be needed.  However,
in today's world, many user agent implementations do not have support
for generating local announcements.

Advantages for "event based local announcements"
a) requires no network bandwidth
b) requires no annoucements server

Disadvantages for "event based local announcements"
a) Not all SIP user agents support locally generated announcements
b) provisioning issues for large-scale deployments. (i.e. If desirable,
how would a network admin configure multi-vendor SIP phones in his net
with certain announcements).

Advantages for "event based call diversion"
a) Provides annoucement support in multi-vendor networks across all SIP
user agents
b) Provisioning is centralized at proxy and announcement server

Disadvantages for "event based call diversion"
a) requires network bandwidth to play annoucements
b) requires presence of an announcements server

I'm not interested in a holy war of which to use.  Each solution will be
appropriate for certain network deployments.  There will soon be
implementations of event based local annoucements and event based call
diversion.  The more important issue is to define a mechanism to get
desired feature interaction.



Desired behavior 1: There should be a mechanism so that local
annoucements override network annoucements.

I would like the behavior that locally generated annoucements take
precendence over proxy event based call diversion.  In other words,
given a UA that is configured to play announcement X and proxy that is
configured to divert to an announcement server to play message Y, I want
X to be played.  i.e. I want the behavior of a smart UA to be able to
override the behavior (provided by proxies in the network) to dumb UAs.

Unfortunately, Po gets a chance to divert the call first:
Proxy: Event based call diversion (recursive)
A                  Po             Pt         AnnServer
|                  |              |             |
|--INV Bob@B------>|              |             |
|                  |--INV Bob@B-->|             |
|                  |<-404---------|             |
|            proxy implements     |             |
|            call forward on 404  |             |
|                  |--INV AnnServer------------>|
|                  |  Diversion: Bob@B          |
|                  |              |             |
|<-200------------------------------------------|
|<==="The URL you have dialed B...O...B is not==|
|     in service, please check the URL or dial  |
|     the operator for assistance"

Solution 1a: Non-recursive implementation of call diversion
A possible solution would be to implement the diversion non-recursively:

Proxy: Event based call diversion (non-recursive)
A                  Po             Pt         AnnServer
|                  |              |             |
|--INV Bob@B------>|              |             |
|                  |--INV Bob@B-->|             |
|                  |<-404---------|             |
|            proxy implements     |             |
|            non-recursive        |             |
|            call forward on 404  |             |
|<-302-------------|              |             |
|  Contact: AnnServer             |             |
|  Diversion: Bob@B; reason=404   |             |
|                  |              |             |
|--INV AnnServer------------------------------->|
|  Diversion: Bob@B; reason=404   |             |
|                  |              |             |
|<-200------------------------------------------|
|<==="The URL you have dialed B...O...B is not==|
|     in service, please check the URL or dial  |
|     the operator for assistance"

then the feature interaction could be:
A ignores 302s with Diversion header indicating reason codes for which A
local generation of annoucements.
Proxy: Event based call diversion (non-recursive)
User agent: Event based local announcement (overriding 302s with already
covered Diversion reason codes)
A                  Po             Pt         AnnServer
|                  |              |             |
|--INV Bob@B------>|              |             |
|                  |--INV Bob@B-->|             |
|                  |<-404---------|             |
|            proxy implements     |             |
|            non-recursive        |             |
|            call forward on 404  |             |
|<-302-------------|              |             |
|  Contact: AnnServer             |             |
|  Diversion: Bob@B; reason=404   |             |
|                  |              |             |
A generates
local audio
indicating
"The URL you have dialed B...O...B is not in service, please check the
 URL or dial the operator for assistance."

Solution 1b: "Supported: annoucements" header
Another possible solution would be for smart UAs (that support
announcements) to use a "Supported: annoucements" header.  This
supported header would be used to indicate to proxies that they should
not implement event based call forwarding (for annoucements):

Proxy: Event based call diversion (deferring implementation to UAC when
"Supported: annoucements" is present)
User agent: Event based local announcement
A                 Po             Pt
|                  |              |
|--INV Bob@B------>|              |
|  Supported: annoucements        |
|                  |              |
|<-404-------------|              |
|                  |              |
A generates
local audio
indicating
"The URL you have dialed B...O...B is not in service, please check the
 URL or dial the operator for assistance."



Desired behavior 2:  There should be a mechanism so that announcements
are not billable.

Another issue that has been raised w/r/t annoucements in networks where
SIP signalling is billable.  The concern is that in SIP networks where
200 is used to write a start record, implementation of proxy event based
call diversion might generate a charge.

Solution 2a: Play annoucements as early media
One solution that has been proposed is to play annoucements as early
media:

For example, recursively:
A                  Po             Pt         AnnServer
|                  |              |             |
|--INV Bob@B------>|              |             |
|                  |--INV Bob@B-->|             |
|                  |<-404---------|             |
|            proxy implements     |             |
|            call forward on 404  |             |
|                  |--INV AnnServer------------>|
|                  |  Diversion: Bob@B          |
|                  |              |             |
|<-183------------------------------------------|
|  Content-Disposition: session                 |
|<==="The URL you have dialed B...O...B is not==|
|     in service, please check the URL or dial  |
|     the operator for assistance"
|<-CANCEL---------------------------------------|
|--200 (CANCEL)-------------------------------->|

or non-recursively:
A                  Po             Pt         AnnServer
|                  |              |             |
|--INV Bob@B------>|              |             |
|                  |--INV Bob@B-->|             |
|                  |<-404---------|             |
|            proxy implements     |             |
|            non-recursive        |             |
|            call forward on 404  |             |
|<-302-------------|              |             |
|  Contact: AnnServer             |             |
|  Diversion: Bob@B; reason=404   |             |
|                  |              |             |
|--INV AnnServer------------------------------->|
|  Diversion: Bob@B; reason=404   |             |
|                  |              |             |
|<-183------------------------------------------|
|  Content-Disposition: session                 |
|<==="The URL you have dialed B...O...B is not==|
|     in service, please check the URL or dial  |
|     the operator for assistance"
|<-CANCEL---------------------------------------|
|--200 (CANCEL)-------------------------------->|

Solution 2b: Backend billing system is aware of (non-billable)
Announcement Server URL
Another possible solution is that the URL of the AnnServer could be
well-known to the backend billing system and that any accounting records
written connection to the AnnServer would not be billed.

I'd like to solicit others' ideas, problems, and proposed solutions
w/r/t annoucements in SIP.

I'm also looking for co-authors to write an I-D w/r/t announcements.  If
interested, please contact me directly at byerly@cisco.com.

thanks for your help,
Bryan

Bryan J. Byerly
byerly@cisco.com



--------------1A5D0555CFDCFCE752C1B2D6
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi guys,
<p>I'd like to solicit ideas/consensus w/r/t announcements in SIP.
<p>For this thread of discussion, we're talking about announcements which
are played when an error occurred during call setup.&nbsp; For instance,
on 404, a message could be played "The URL you have dialed B...O...B. is
not in service, please check the URL or dial the operator for assistance".
<p>There are at least two desired behaviors w/r/t annoucements:
<br>Desired behavior 1: There should be a mechanism so that local annoucements
override network annoucements.
<br>Desired behavior 2: There should be a mechanism so that announcements
are not billable.
<p>Like call forwarding features in SIP, there are implementable solutions
to play annoucements using user agents or proxies.
<p>In the diagrams below, A, B, and C are user agents, Po is an originating
proxy and Pt is a terminating proxy.
<p>User agent: Event based local announcement
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt</tt>
<br><tt>|&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;
|</tt>
<br><tt>|--INV Bob@B------>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;
|</tt>
<br><tt>|&lt;-404-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;
|</tt>
<br><tt>A generates</tt>
<br><tt>local audio</tt>
<br><tt>indicating</tt>
<br><tt>"The URL you have dialed B...O...B is not in service, please check
the</tt>
<br><tt>&nbsp;URL or dial the operator for assistance."</tt>
<br>&nbsp;
<p>Proxy: Event based call diversion (recursive)
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Announcement</tt>
<br><tt>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Server</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV AnnServer------------>|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Diversion: Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-200------------------------------------------|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<br>&nbsp;
<p>Both approaches are viable and there are advantages/disadvantages to
each.&nbsp; If all user agents supported local generation of announcements,
then an event based call diversion solution may not be needed.&nbsp; However,
in today's world, many user agent implementations do not have support for
generating local announcements.
<p>Advantages for "event based local announcements"
<br>a) requires no network bandwidth
<br>b) requires no annoucements server
<p>Disadvantages for "event based local announcements"
<br>a) Not all SIP user agents support locally generated announcements
<br>b) provisioning issues for large-scale deployments. (i.e. If desirable,
how would a network admin configure multi-vendor SIP phones in his net
with certain announcements).
<p>Advantages for "event based call diversion"
<br>a) Provides annoucement support in multi-vendor networks across all
SIP user agents
<br>b) Provisioning is centralized at proxy and announcement server
<p>Disadvantages for "event based call diversion"
<br>a) requires network bandwidth to play annoucements
<br>b) requires presence of an announcements server
<p>I'm not interested in a holy war of which to use.&nbsp; Each solution
will be appropriate for certain network deployments.&nbsp; There will soon
be implementations of event based local annoucements and event based call
diversion.&nbsp; The more important issue is to define a mechanism to get
desired feature interaction.
<br>&nbsp;
<br>&nbsp;
<p>Desired behavior 1: There should be a mechanism so that local annoucements
override network annoucements.
<p>I would like the behavior that locally generated annoucements take precendence
over proxy event based call diversion.&nbsp; In other words, given a UA
that is configured to play announcement X and proxy that is configured
to divert to an announcement server to play message Y, I want X to be played.&nbsp;
i.e. I want the behavior of a smart UA to be able to override the behavior
(provided by proxies in the network) to dumb UAs.
<p>Unfortunately, Po gets a chance to divert the call first:
<br>Proxy: Event based call diversion (recursive)
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV AnnServer------------>|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Diversion: Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-200------------------------------------------|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<p>Solution 1a: Non-recursive implementation of call diversion
<br>A possible solution would be to implement the diversion non-recursively:
<br>Proxy: Event based call diversion (non-recursive)
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-302-------------|&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;
|</tt>
<br><tt>|&nbsp; Contact: AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV AnnServer------------------------------->|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-200------------------------------------------|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<p>then the feature interaction could be:
<br>A ignores 302s with Diversion header indicating reason codes for which
A local generation of annoucements.
<br>Proxy: Event based call diversion (non-recursive)
<br>User agent: Event based local announcement (overriding 302s with already
covered Diversion reason codes)
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-302-------------|&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;
|</tt>
<br><tt>|&nbsp; Contact: AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>A generates</tt>
<br><tt>local audio</tt>
<br><tt>indicating</tt>
<br><tt>"The URL you have dialed B...O...B is not in service, please check
the</tt>
<br><tt>&nbsp;URL or dial the operator for assistance."</tt>
<p>Solution 1b: "Supported: annoucements" header
<br>Another possible solution would be for smart UAs (that support announcements)
to use a "Supported: annoucements" header.&nbsp; This supported header
would be used to indicate to proxies that they should not implement event
based call forwarding (for annoucements):
<p>Proxy: Event based call diversion (deferring implementation to UAC when
"Supported: annoucements" is present)
<br>User agent: Event based local announcement
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt</tt>
<br><tt>|&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;
|</tt>
<br><tt>|--INV Bob@B------>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp; Supported: annoucements&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;
|</tt>
<br><tt>|&lt;-404-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;
|</tt>
<br><tt>A generates</tt>
<br><tt>local audio</tt>
<br><tt>indicating</tt>
<br><tt>"The URL you have dialed B...O...B is not in service, please check
the</tt>
<br><tt>&nbsp;URL or dial the operator for assistance."</tt>
<br>&nbsp;
<br>&nbsp;
<p>Desired behavior 2:&nbsp; There should be a mechanism so that announcements
are not billable.
<p>Another issue that has been raised w/r/t annoucements in networks where
SIP signalling is billable.&nbsp; The concern is that in SIP networks where
200 is used to write a start record, implementation of proxy event based
call diversion might generate a charge.
<p>Solution 2a: Play annoucements as early media
<br>One solution that has been proposed is to play annoucements as early
media:
<p>For example, recursively:
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV AnnServer------------>|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Diversion: Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-183------------------------------------------|</tt>
<br><tt>|&nbsp; Content-Disposition: session&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<br><tt>|&lt;-CANCEL---------------------------------------|</tt>
<br><tt>|--200 (CANCEL)-------------------------------->|</tt>
<p>or non-recursively:
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-302-------------|&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;
|</tt>
<br><tt>|&nbsp; Contact: AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV AnnServer------------------------------->|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-183------------------------------------------|</tt>
<br><tt>|&nbsp; Content-Disposition: session&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<br><tt>|&lt;-CANCEL---------------------------------------|</tt>
<br><tt>|--200 (CANCEL)-------------------------------->|</tt>
<p>Solution 2b: Backend billing system is aware of (non-billable) Announcement
Server URL
<br>Another possible solution is that the URL of the AnnServer could be
well-known to the backend billing system and that any accounting records
written connection to the AnnServer would not be billed.
<p>I'd like to solicit others' ideas, problems, and proposed solutions
w/r/t annoucements in SIP.
<p>I'm also looking for co-authors to write an I-D w/r/t announcements.&nbsp;
If interested, please contact me directly at byerly@cisco.com.
<p>thanks for your help,
<br>Bryan
<p>Bryan J. Byerly
<br>byerly@cisco.com
<br>&nbsp;
<br>&nbsp;</html>

--------------1A5D0555CFDCFCE752C1B2D6--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 22 12:22:52 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09417
	for <sip-archive@odin.ietf.org>; Mon, 22 Jan 2001 12:22:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2D84C44353; Mon, 22 Jan 2001 11:23:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id F2AF444351
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 11:22:41 -0500 (EST)
Received: (qmail 19051 invoked by uid 500); 22 Jan 2001 17:27:20 -0000
From: David Frascone <dave@frascone.com>
To: sip@lists.bell-labs.com
Subject: RE: [SIP] T2 and 182 Queued
Message-ID: <20010122112719.C18913@newman.frascone.com>
Mail-Followup-To: sip@lists.bell-labs.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 22 Jan 2001 11:27:19 -0600

Given this forwarded discussion, this might be an error in 02bis.

----- Forwarded message from Jo Hornsby <jhornsby@ubiquity.net> -----

From: "Jo Hornsby" <jhornsby@ubiquity.net>
To: "David Frascone" <dave@frascone.com>, <sip-implementors@cs.columbia.edu>
Subject: RE: [SIP] T2 and 182 Queued
Date: Mon, 22 Jan 2001 15:47:36 -0000
Message-ID: <000001c0848a$a4281f20$4e34c3c1@ubiquity.co.uk>

David Frascone wrote:
>
> Does anyone know the answer to this?  Should I switch to the sip list?
>
>
> On Fri, Jan 19, 2001 at 11:16:13AM -0600, David Frascone wrote:
> > From section 10.2.1:
> >
> >    Subsequent retransmissions are spaced by T2 seconds. If the client
> >    receives a provisional response, it continues to retransmit the
> >    request, but with an interval of T2 seconds. Retransmissions cease
> >    when the client has sent a total of eleven packets, or receives a
> >    definitive response. Default values for T1 and T2 are 500 ms and 4 s,
> >    respectively. Clients MAY use larger values, but SHOULDNOT use
> >    smaller ones. Servers retransmit the response upon receipt of a
> >
> > Which means, the INVITE would be retransmitted every 4 seconds
> > while the caller is waiting in the queue.  And, would stop after
> > 11 retransmissions, or 44 seconds, which is still too small for
> > some queues.

You are correct -- the text you quoted does say this.  However,
if you seek to the beginning of the same paragraph, you find:

   A SIP client using an unreliable transport protocol such as UDP
   SHOULD retransmit requests other than INVITE or ACK [...]

Look to section 10.3 for reliability-related behaviour for INVITEs.


 - Jo.


----- End forwarded message -----

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 22 12:31:55 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09646
	for <sip-archive@odin.ietf.org>; Mon, 22 Jan 2001 12:31:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EAF4C4435E; Mon, 22 Jan 2001 11:32:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id 041C34435E
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 11:31:16 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 22 Jan 2001 17:31:03 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id RAA12208; Mon, 22 Jan 2001 17:29:45 GMT
From: "Jo Hornsby" <jhornsby@ubiquity.net>
To: "David Frascone" <dave@frascone.com>, <sip@lists.bell-labs.com>
Subject: RE: [SIP] T2 and 182 Queued
Message-ID: <000b01c08498$e97ccea0$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <20010122112719.C18913@newman.frascone.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 22 Jan 2001 17:29:45 -0000
Content-Transfer-Encoding: 7bit

David Frascone wrote:
> Given this forwarded discussion, this might be an error in 02bis.

It might be.  But given the fact that section 10.2 is entitled:
"Reliability for Requests Other Than INVITE", I suspect it is not. &:)

> ----- Forwarded message from Jo Hornsby <jhornsby@ubiquity.net> -----
> 
> From: "Jo Hornsby" <jhornsby@ubiquity.net>
> To: "David Frascone" <dave@frascone.com>, 
> <sip-implementors@cs.columbia.edu>
> Subject: RE: [SIP] T2 and 182 Queued
> Date: Mon, 22 Jan 2001 15:47:36 -0000
> Message-ID: <000001c0848a$a4281f20$4e34c3c1@ubiquity.co.uk>
> 
> David Frascone wrote:
> >
> > Does anyone know the answer to this?  Should I switch to the sip list?
> >
> >
> > On Fri, Jan 19, 2001 at 11:16:13AM -0600, David Frascone wrote:
> > > From section 10.2.1:
> > >
> > >    Subsequent retransmissions are spaced by T2 seconds. If the client
> > >    receives a provisional response, it continues to retransmit the
> > >    request, but with an interval of T2 seconds. Retransmissions cease
> > >    when the client has sent a total of eleven packets, or receives a
> > >    definitive response. Default values for T1 and T2 are 500 
> ms and 4 s,
> > >    respectively. Clients MAY use larger values, but SHOULDNOT use
> > >    smaller ones. Servers retransmit the response upon receipt of a
> > >
> > > Which means, the INVITE would be retransmitted every 4 seconds
> > > while the caller is waiting in the queue.  And, would stop after
> > > 11 retransmissions, or 44 seconds, which is still too small for
> > > some queues.
> 
> You are correct -- the text you quoted does say this.  However,
> if you seek to the beginning of the same paragraph, you find:
> 
>    A SIP client using an unreliable transport protocol such as UDP
>    SHOULD retransmit requests other than INVITE or ACK [...]
> 
> Look to section 10.3 for reliability-related behaviour for INVITEs.
> 
> 
>  - Jo.
> 
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 22 12:37:13 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09791
	for <sip-archive@odin.ietf.org>; Mon, 22 Jan 2001 12:37:12 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AE56544368; Mon, 22 Jan 2001 11:36:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from email5.etsi.org (email5.etsi.fr [212.234.161.50])
	by lists.bell-labs.com (Postfix) with ESMTP id 5161D44368
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 11:35:07 -0500 (EST)
Received: by EMAIL5 with Internet Mail Service (5.5.2650.21)
	id <CTC9W4R7>; Mon, 22 Jan 2001 18:34:47 +0100
Message-ID: <337FC70FD51CD411A3500008C70D56F1500236@IS~EMAIL1>
From: Nathalie Guinet <Nathalie.Guinet@etsi.fr>
To: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Reminder to SIP Bake-off Participants in France (26-30 March 2001
 )  -  Hotel room booking
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 22 Jan 2001 18:34:50 +0100

Dear SIP Bake-off participants,

Please note that the Early Bird Room Rate of the Royal Hotel Casino is valid
until 31st January 2001. After that date, the rate will be increased.

You may use this form to make your booking.
http://webapp.etsi.org/interop3/doc/registration.doc

Feel free to contact me should you have any worries with this.

Nathalie Guinet
ETSI Bake-off Service
Event Coordinator
Tel: +33 (0)4 92 94 43 62
Fax: + 33 (0)4 92 38 49 13


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 22 12:45:26 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10012
	for <sip-archive@odin.ietf.org>; Mon, 22 Jan 2001 12:45:25 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5C3B74436E; Mon, 22 Jan 2001 11:43:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id 44C0D4436D
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 11:42:26 -0500 (EST)
Received: (qmail 19135 invoked by uid 500); 22 Jan 2001 17:47:04 -0000
From: David Frascone <dave@frascone.com>
To: sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
Message-ID: <20010122114703.B19062@newman.frascone.com>
Mail-Followup-To: sip@lists.bell-labs.com
References: <20010122112719.C18913@newman.frascone.com> <000b01c08498$e97ccea0$4e34c3c1@ubiquity.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <000b01c08498$e97ccea0$4e34c3c1@ubiquity.co.uk>; from jhornsby@ubiquity.net on Mon, Jan 22, 2001 at 05:29:45PM -0000
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 22 Jan 2001 11:47:03 -0600

You are right.  I did copy the wrong paragraph.  But, I still can't find 
anywhere in 10.3 that stops the T2 timer.  It says that provisional responses
are re-sent upon every duplicate request, but it never resets the T2 timer.

My concern is not retransmissions, but the total call setup time, which 
could take much longer than T2 allows, if the call is queued.

Now, if the timers are just a suggestion, and the user agent can do whatever
it wants, then this is not a problem.  I know that I can set T1 and T2 to
whatever values I want, but I'd prefer to have a queued call work within
the "suggested" parameters of 500ms and 4sec as set by the RFC.

Comments?  Does anyone really care?  Should I ignore this, and just set my
T2 timer really high?



On Mon, Jan 22, 2001 at 05:29:45PM -0000, Jo Hornsby wrote:
> David Frascone wrote:
> > Given this forwarded discussion, this might be an error in 02bis.
> 
> It might be.  But given the fact that section 10.2 is entitled:
> "Reliability for Requests Other Than INVITE", I suspect it is not. &:)
> 
> > ----- Forwarded message from Jo Hornsby <jhornsby@ubiquity.net> -----
> > 
> > From: "Jo Hornsby" <jhornsby@ubiquity.net>
> > To: "David Frascone" <dave@frascone.com>, 
> > <sip-implementors@cs.columbia.edu>
> > Subject: RE: [SIP] T2 and 182 Queued
> > Date: Mon, 22 Jan 2001 15:47:36 -0000
> > Message-ID: <000001c0848a$a4281f20$4e34c3c1@ubiquity.co.uk>
> > 
> > David Frascone wrote:
> > >
> > > Does anyone know the answer to this?  Should I switch to the sip list?
> > >
> > >
> > > On Fri, Jan 19, 2001 at 11:16:13AM -0600, David Frascone wrote:
> > > > From section 10.2.1:
> > > >
> > > >    Subsequent retransmissions are spaced by T2 seconds. If the client
> > > >    receives a provisional response, it continues to retransmit the
> > > >    request, but with an interval of T2 seconds. Retransmissions cease
> > > >    when the client has sent a total of eleven packets, or receives a
> > > >    definitive response. Default values for T1 and T2 are 500 
> > ms and 4 s,
> > > >    respectively. Clients MAY use larger values, but SHOULDNOT use
> > > >    smaller ones. Servers retransmit the response upon receipt of a
> > > >
> > > > Which means, the INVITE would be retransmitted every 4 seconds
> > > > while the caller is waiting in the queue.  And, would stop after
> > > > 11 retransmissions, or 44 seconds, which is still too small for
> > > > some queues.
> > 
> > You are correct -- the text you quoted does say this.  However,
> > if you seek to the beginning of the same paragraph, you find:
> > 
> >    A SIP client using an unreliable transport protocol such as UDP
> >    SHOULD retransmit requests other than INVITE or ACK [...]
> > 
> > Look to section 10.3 for reliability-related behaviour for INVITEs.
> > 
> > 
> >  - Jo.
> > 
> > 
> > ----- End forwarded message -----
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> > 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 22 13:11:55 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10736
	for <sip-archive@odin.ietf.org>; Mon, 22 Jan 2001 13:11:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1AC5F44361; Mon, 22 Jan 2001 12:11:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cybertron.div8.net (HSE-Kitchener-ppp320837.sympatico.ca [64.231.176.84])
	by lists.bell-labs.com (Postfix) with ESMTP id 3A38744351
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 12:10:14 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m14KlRg-003EreC@cybertron.div8.net> (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Mon, 22 Jan 2001 13:12:00 -0500 (EST) 
From: Billy Biggs <billy@billybiggs.com>
To: SIP List <sip@lists.bell-labs.com>
Message-ID: <20010122131200.B494@div8.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [SIP] Transfer Primitives
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 22 Jan 2001 13:12:00 -0500

  Here is my vision for SIP transfer primitives.  This is my personal
opinion, and is not reflected in any of the current drafts.

  I see three distinct primitives:

  1. HANDOFF
      - 3-way call handoff and blind transfer with recovery-on-fail.
      - Transferee never mixes, media stops when HANDOFF accepted.
      - Status is sent using a header in BYE (leave old call) or
        re-INVITE (regain old call).

  2. JOIN
      - Transferee-mixes attended transfer.
      - Request a conference bridge to call-in another party.
      - Status is optionally sent using a NOTIFY (implicit subscribe).

  3. REFER
      - Refer a person to a URL.
      - Useful to refer someone to an HTTP URL, or tell someone a SIP
        URL for their address book.
      - Interactive pop-up with a 'view in browser' or 'save to
        bookmarks' etc.
      - Status is never sent (doesn't make sense with most URL schemes).

  I believe that the implementation of these is sufficiently distinct to
warrant seperate methods.  I expect everybody to implement HANDOFF for
basic call transfer, and a smaller group to implement REFER/JOIN for
more advanced services.

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 22 14:41:56 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12932
	for <sip-archive@odin.ietf.org>; Mon, 22 Jan 2001 14:41:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id ED3DD44351; Mon, 22 Jan 2001 13:42:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by lists.bell-labs.com (Postfix) with ESMTP id 72B4944350
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 13:41:47 -0500 (EST)
Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16])
	by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA25465;
	Mon, 22 Jan 2001 14:41:14 -0500 (EST)
Received: from cisco.com (rtp-ptdxdm1.cisco.com [64.102.17.217])
	by dingdong.cisco.com (Mirapoint)
	with ESMTP id AAL19279 (AUTH byerly);
	Mon, 22 Jan 2001 14:41:31 -0500 (EST)
Message-ID: <3A6C8CEA.E77B1FBC@cisco.com>
From: Bryan Byerly <byerly@cisco.com>
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Venkatesh Venkataramanan <Venkatesh.Venkataramanan@sylantro.com>,
        sip@lists.bell-labs.com
Cc: byerly@cisco.com
Subject: Re: [SIP] Announcements in SIP
References: <79FEAA5FABA7D411BF580001023D1BBD26D7E8@mailserver.sylantro.com>
Content-Type: multipart/alternative;
 boundary="------------258BA5EA253D69046A922F03"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 22 Jan 2001 14:41:30 -0500


--------------258BA5EA253D69046A922F03
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Venkatesh Venkataramanan wrote:

>  Alternate Suggestion:If I understand 404 response right, all that the
> proxies do today is to forward them down to the UA. So, instead of
> making the proxy either translate the 404 to a 302 or implementing
> call forwarding to an annc server on receipt of a 404, I was thinking
> more on the lines of just forwarding the 404 response down to the UA,
> very much like today, except that the proxy adds a Contact:
> AnncServer_URL. A smart UA (that can provide local annc would do so,
> seeing the 404) where as a UA that doesn't have any local playback
> capabilities would contact the Contact: URL to provide local
> announcements. So, no extensions involved (except the work of adding a
> Contact in a 404 response). Any thoughts on this suggestion?

The approach using a Contact in the response would also work for smart
UAs.

A              Po             Pt           AnnServer
|              |              |                |
|--INV Bob@Po->|              |                |
|              |--INV Bob@Pt->|                |
|              |              |                |
|              |<-404---------|                |
|              |              |                |
|<-404---------|              |                |
|  Contact: AnnServer         |                |
|              |              |                |
|--INV AnnServer------------------------------>|
|              |              |                |
|<-183/200-------------------------------------|
|              |              |                |
|<="The URL you have dialed B...O...B at Pt is=|
|   unrouteable, please check the URL or       |
|   contact your system admin for assistance"  |



However,
a) this doesn't provide an announcements solution for dumb UAs
b) I doubt a smart UA would even need an AnnServer contact.  Since he's
smart, he would either 1) be able to generate annoucements locally or
2) know the FQDN/IP address of the AnnServer directly.  I'm not aware
that smart UAs need any proxy assist. (Although, they would need to be
able to turn off proxy assist).

In the proposal above, how would the Announcement server know to say
"B...O...B"?
One solution would be for the Annoucement server to examine the
Diversion header (draft-levy-sip-diversion-01.txt).  The Diversion
header provides the necessary supplemental information to the
announcement server.  Since the Diversion header is already needed for
voicemail servers, I think it is a good candidate for usage here.

What do you think?

thanks,
Bryan

Bryan J. Byerly
byerly@cisco.com


>      -----Original Message-----
>      From: Bryan Byerly [mailto:byerly@cisco.com]
>      Sent: Monday, January 22, 2001 8:54 AM
>      To: sip@lists.bell-labs.com
>      Cc: byerly@cisco.com
>      Subject: [SIP] Announcements in SIP
>
>      Hi guys,
>
>      I'd like to solicit ideas/consensus w/r/t announcements in
>      SIP.
>
>      For this thread of discussion, we're talking about
>      announcements which are played when an error occurred during
>      call setup.  For instance, on 404, a message could be played
>      "The URL you have dialed B...O...B. is not in service,
>      please check the URL or dial the operator for assistance".
>
>      There are at least two desired behaviors w/r/t annoucements:
>
>      Desired behavior 1: There should be a mechanism so that
>      local annoucements override network annoucements.
>      Desired behavior 2: There should be a mechanism so that
>      announcements are not billable.
>
>      Like call forwarding features in SIP, there are
>      implementable solutions to play annoucements using user
>      agents or proxies.
>
>      In the diagrams below, A, B, and C are user agents, Po is an
>      originating proxy and Pt is a terminating proxy.
>
>      User agent: Event based local announcement
>      A                 Po             Pt
>      |                  |              |
>      |--INV Bob@B------>|              |
>      |                  |              |
>      |<-404-------------|              |
>      |                  |              |
>      A generates
>      local audio
>      indicating
>      "The URL you have dialed B...O...B is not in service, please
>      check the
>       URL or dial the operator for assistance."
>
>
>      Proxy: Event based call diversion (recursive)
>      A                  Po             Pt        Announcement
>                                                    Server
>      |                  |              |             |
>      |--INV Bob@B------>|              |             |
>      |                  |--INV Bob@B-->|             |
>      |                  |<-404---------|             |
>      |            proxy implements     |             |
>      |            call forward on 404  |             |
>      |                  |--INV AnnServer------------>|
>      |                  |  Diversion: Bob@B          |
>      |                  |              |             |
>      |<-200------------------------------------------|
>      |<==="The URL you have dialed B...O...B is not==|
>      |     in service, please check the URL or dial  |
>      |     the operator for assistance"
>
>
>      Both approaches are viable and there are
>      advantages/disadvantages to each.  If all user agents
>      supported local generation of announcements, then an event
>      based call diversion solution may not be needed.  However,
>      in today's world, many user agent implementations do not
>      have support for generating local announcements.
>
>      Advantages for "event based local announcements"
>      a) requires no network bandwidth
>      b) requires no annoucements server
>
>      Disadvantages for "event based local announcements"
>      a) Not all SIP user agents support locally generated
>      announcements
>      b) provisioning issues for large-scale deployments. (i.e. If
>      desirable, how would a network admin configure multi-vendor
>      SIP phones in his net with certain announcements).
>
>      Advantages for "event based call diversion"
>      a) Provides annoucement support in multi-vendor networks
>      across all SIP user agents
>      b) Provisioning is centralized at proxy and announcement
>      server
>
>      Disadvantages for "event based call diversion"
>      a) requires network bandwidth to play annoucements
>      b) requires presence of an announcements server
>
>      I'm not interested in a holy war of which to use.  Each
>      solution will be appropriate for certain network
>      deployments.  There will soon be implementations of event
>      based local annoucements and event based call diversion.
>      The more important issue is to define a mechanism to get
>      desired feature interaction.
>
>
>
>      Desired behavior 1: There should be a mechanism so that
>      local annoucements override network annoucements.
>
>      I would like the behavior that locally generated
>      annoucements take precendence over proxy event based call
>      diversion.  In other words, given a UA that is configured to
>      play announcement X and proxy that is configured to divert
>      to an announcement server to play message Y, I want X to be
>      played.  i.e. I want the behavior of a smart UA to be able
>      to override the behavior (provided by proxies in the
>      network) to dumb UAs.
>
>      Unfortunately, Po gets a chance to divert the call first:
>      Proxy: Event based call diversion (recursive)
>      A                  Po             Pt         AnnServer
>      |                  |              |             |
>      |--INV Bob@B------>|              |             |
>      |                  |--INV Bob@B-->|             |
>      |                  |<-404---------|             |
>      |            proxy implements     |             |
>      |            call forward on 404  |             |
>      |                  |--INV AnnServer------------>|
>      |                  |  Diversion: Bob@B          |
>      |                  |              |             |
>      |<-200------------------------------------------|
>      |<==="The URL you have dialed B...O...B is not==|
>      |     in service, please check the URL or dial  |
>      |     the operator for assistance"
>
>      Solution 1a: Non-recursive implementation of call diversion
>      A possible solution would be to implement the diversion
>      non-recursively:
>      Proxy: Event based call diversion (non-recursive)
>      A                  Po             Pt         AnnServer
>      |                  |              |             |
>      |--INV Bob@B------>|              |             |
>      |                  |--INV Bob@B-->|             |
>      |                  |<-404---------|             |
>      |            proxy implements     |             |
>      |            non-recursive        |             |
>      |            call forward on 404  |             |
>      |<-302-------------|              |             |
>      |  Contact: AnnServer             |             |
>      |  Diversion: Bob@B; reason=404   |             |
>      |                  |              |             |
>      |--INV AnnServer------------------------------->|
>      |  Diversion: Bob@B; reason=404   |             |
>      |                  |              |             |
>      |<-200------------------------------------------|
>      |<==="The URL you have dialed B...O...B is not==|
>      |     in service, please check the URL or dial  |
>      |     the operator for assistance"
>
>      then the feature interaction could be:
>      A ignores 302s with Diversion header indicating reason codes
>      for which A local generation of annoucements.
>      Proxy: Event based call diversion (non-recursive)
>      User agent: Event based local announcement (overriding 302s
>      with already covered Diversion reason codes)
>      A                  Po             Pt         AnnServer
>      |                  |              |             |
>      |--INV Bob@B------>|              |             |
>      |                  |--INV Bob@B-->|             |
>      |                  |<-404---------|             |
>      |            proxy implements     |             |
>      |            non-recursive        |             |
>      |            call forward on 404  |             |
>      |<-302-------------|              |             |
>      |  Contact: AnnServer             |             |
>      |  Diversion: Bob@B; reason=404   |             |
>      |                  |              |             |
>      A generates
>      local audio
>      indicating
>      "The URL you have dialed B...O...B is not in service, please
>      check the
>       URL or dial the operator for assistance."
>
>      Solution 1b: "Supported: annoucements" header
>      Another possible solution would be for smart UAs (that
>      support announcements) to use a "Supported: annoucements"
>      header.  This supported header would be used to indicate to
>      proxies that they should not implement event based call
>      forwarding (for annoucements):
>
>      Proxy: Event based call diversion (deferring implementation
>      to UAC when "Supported: annoucements" is present)
>      User agent: Event based local announcement
>      A                 Po             Pt
>      |                  |              |
>      |--INV Bob@B------>|              |
>      |  Supported: annoucements        |
>      |                  |              |
>      |<-404-------------|              |
>      |                  |              |
>      A generates
>      local audio
>      indicating
>      "The URL you have dialed B...O...B is not in service, please
>      check the
>       URL or dial the operator for assistance."
>
>
>
>      Desired behavior 2:  There should be a mechanism so that
>      announcements are not billable.
>
>      Another issue that has been raised w/r/t annoucements in
>      networks where SIP signalling is billable.  The concern is
>      that in SIP networks where 200 is used to write a start
>      record, implementation of proxy event based call diversion
>      might generate a charge.
>
>      Solution 2a: Play annoucements as early media
>      One solution that has been proposed is to play annoucements
>      as early media:
>
>      For example, recursively:
>      A                  Po             Pt         AnnServer
>      |                  |              |             |
>      |--INV Bob@B------>|              |             |
>      |                  |--INV Bob@B-->|             |
>      |                  |<-404---------|             |
>      |            proxy implements     |             |
>      |            call forward on 404  |             |
>      |                  |--INV AnnServer------------>|
>      |                  |  Diversion: Bob@B          |
>      |                  |              |             |
>      |<-183------------------------------------------|
>      |  Content-Disposition: session                 |
>      |<==="The URL you have dialed B...O...B is not==|
>      |     in service, please check the URL or dial  |
>      |     the operator for assistance"
>      |<-CANCEL---------------------------------------|
>      |--200 (CANCEL)-------------------------------->|
>
>      or non-recursively:
>      A                  Po             Pt         AnnServer
>      |                  |              |             |
>      |--INV Bob@B------>|              |             |
>      |                  |--INV Bob@B-->|             |
>      |                  |<-404---------|             |
>      |            proxy implements     |             |
>      |            non-recursive        |             |
>      |            call forward on 404  |             |
>      |<-302-------------|              |             |
>      |  Contact: AnnServer             |             |
>      |  Diversion: Bob@B; reason=404   |             |
>      |                  |              |             |
>      |--INV AnnServer------------------------------->|
>      |  Diversion: Bob@B; reason=404   |             |
>      |                  |              |             |
>      |<-183------------------------------------------|
>      |  Content-Disposition: session                 |
>      |<==="The URL you have dialed B...O...B is not==|
>      |     in service, please check the URL or dial  |
>      |     the operator for assistance"
>      |<-CANCEL---------------------------------------|
>      |--200 (CANCEL)-------------------------------->|
>
>      Solution 2b: Backend billing system is aware of
>      (non-billable) Announcement Server URL
>      Another possible solution is that the URL of the AnnServer
>      could be well-known to the backend billing system and that
>      any accounting records written connection to the AnnServer
>      would not be billed.
>
>      I'd like to solicit others' ideas, problems, and proposed
>      solutions w/r/t annoucements in SIP.
>
>      I'm also looking for co-authors to write an I-D w/r/t
>      announcements.  If interested, please contact me directly at
>      byerly@cisco.com.
>
>      thanks for your help,
>      Bryan
>
>      Bryan J. Byerly
>      byerly@cisco.com
>
>
>



--------------258BA5EA253D69046A922F03
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Venkatesh Venkataramanan wrote:
<blockquote TYPE=CITE>&nbsp;<span 
class=593565817-22012001><font face="Arial"><font color="#0000FF"><font size=-1>Alternate
Suggestion:</font></font></font></span><span class=593565817-22012001><font face="Arial"><font color="#0000FF"><font size=-1>If
I understand 404 response right, all that the proxies do today is to forward
them down to the UA. So, instead of making the proxy either translate the
404 to a 302 or implementing call forwarding to an annc server on receipt
of a 404, I was thinking more on the lines of just forwarding the 404 response
down to the UA, very much like today, except that the proxy adds a Contact:
AnncServer_URL. A smart UA (that can provide local annc would do so, seeing
the 404) where as a UA that doesn't have any local playback capabilities
would contact the Contact: URL to provide local announcements. So, no extensions
involved (except the work of adding a Contact in a 404 response).</font></font></font></span>&nbsp;<span class=593565817-22012001><font face="Arial"><font color="#0000FF"><font size=-1>Any
thoughts on this suggestion?</font></font></font></span></blockquote>

<p><br>The approach using a Contact in the response would also work for
smart UAs.
<p><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;
|</tt>
<br><tt>|--INV Bob@Po->|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@Pt->|&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;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;
|</tt>
<br><tt>|&lt;-404---------|&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;
|</tt>
<br><tt>| &nbsp;Contact:&nbsp;AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;
|</tt>
<br><tt>|--INV AnnServer------------------------------>|</tt>
<br><tt>|&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;&nbsp;
|</tt>
<br><tt>|&lt;-183/200-------------------------------------|</tt>
<br><tt>|&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;&nbsp;
|</tt>
<br><tt>|&lt;="The URL&nbsp;you have dialed B...O...B at Pt is=|</tt>
<br><tt>|&nbsp;&nbsp; unrouteable, please check the URL&nbsp;or&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp; contact your system admin for assistance"&nbsp; |</tt>
<br>&nbsp;
<br>&nbsp;
<p>However,
<br>a)&nbsp;this doesn't provide an announcements solution for dumb UAs
<br>b)&nbsp;I doubt a smart UA&nbsp;would even need an AnnServer contact.&nbsp;
Since he's smart, he would either 1)&nbsp;be able to generate annoucements
locally or 2)&nbsp;know the FQDN/IP&nbsp;address of the AnnServer directly.&nbsp;
I'm not aware that smart UAs need any proxy assist. (Although, they would
need to be able to turn off proxy assist).
<p>In the proposal above, how would the Announcement server know to say
"B...O...B"?
<br>One solution would be for the Annoucement server to examine the Diversion
header (draft-levy-sip-diversion-01.txt).&nbsp; The Diversion header provides
the necessary supplemental information to the announcement server.&nbsp;
Since the Diversion header is already needed for voicemail servers, I&nbsp;think
it is a good candidate for usage here.
<p>What do you think?
<p>thanks,
<br>Bryan
<p>Bryan J. Byerly
<br>byerly@cisco.com
<br>&nbsp;
<blockquote TYPE=CITE>
<blockquote style="MARGIN-RIGHT: 0px">
<div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Bryan Byerly [<A HREF="mailto:byerly@cisco.com">mailto:byerly@cisco.com</A>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Monday, January 22,
2001 8:54 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> sip@lists.bell-labs.com</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> byerly@cisco.com</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> [SIP] Announcements
in SIP</font></font>
<br>&nbsp;</div>
Hi guys,
<p>I'd like to solicit ideas/consensus w/r/t announcements in SIP.
<p>For this thread of discussion, we're talking about announcements which
are played when an error occurred during call setup.&nbsp; For instance,
on 404, a message could be played "The URL you have dialed B...O...B. is
not in service, please check the URL or dial the operator for assistance".
<p>There are at least two desired behaviors w/r/t annoucements:
<br>Desired behavior 1: There should be a mechanism so that local annoucements
override network annoucements.
<br>Desired behavior 2: There should be a mechanism so that announcements
are not billable.
<p>Like call forwarding features in SIP, there are implementable solutions
to play annoucements using user agents or proxies.
<p>In the diagrams below, A, B, and C are user agents, Po is an originating
proxy and Pt is a terminating proxy.
<p>User agent: Event based local announcement
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt</tt>
<br><tt>|&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;
|</tt>
<br><tt>|--INV Bob@B------>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;
|</tt>
<br><tt>|&lt;-404-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;
|</tt>
<br><tt>A generates</tt>
<br><tt>local audio</tt>
<br><tt>indicating</tt>
<br><tt>"The URL you have dialed B...O...B is not in service, please check
the</tt>
<br><tt>&nbsp;URL or dial the operator for assistance."</tt>
<br>&nbsp;
<p>Proxy: Event based call diversion (recursive)
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Announcement</tt>
<br><tt>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Server</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV AnnServer------------>|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Diversion: Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-200------------------------------------------|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<br>&nbsp;
<p>Both approaches are viable and there are advantages/disadvantages to
each.&nbsp; If all user agents supported local generation of announcements,
then an event based call diversion solution may not be needed.&nbsp; However,
in today's world, many user agent implementations do not have support for
generating local announcements.
<p>Advantages for "event based local announcements"
<br>a) requires no network bandwidth
<br>b) requires no annoucements server
<p>Disadvantages for "event based local announcements"
<br>a) Not all SIP user agents support locally generated announcements
<br>b) provisioning issues for large-scale deployments. (i.e. If desirable,
how would a network admin configure multi-vendor SIP phones in his net
with certain announcements).
<p>Advantages for "event based call diversion"
<br>a) Provides annoucement support in multi-vendor networks across all
SIP user agents
<br>b) Provisioning is centralized at proxy and announcement server
<p>Disadvantages for "event based call diversion"
<br>a) requires network bandwidth to play annoucements
<br>b) requires presence of an announcements server
<p>I'm not interested in a holy war of which to use.&nbsp; Each solution
will be appropriate for certain network deployments.&nbsp; There will soon
be implementations of event based local annoucements and event based call
diversion.&nbsp; The more important issue is to define a mechanism to get
desired feature interaction.
<br>&nbsp;
<br>&nbsp;
<p>Desired behavior 1: There should be a mechanism so that local annoucements
override network annoucements.
<p>I would like the behavior that locally generated annoucements take precendence
over proxy event based call diversion.&nbsp; In other words, given a UA
that is configured to play announcement X and proxy that is configured
to divert to an announcement server to play message Y, I want X to be played.&nbsp;
i.e. I want the behavior of a smart UA to be able to override the behavior
(provided by proxies in the network) to dumb UAs.
<p>Unfortunately, Po gets a chance to divert the call first:
<br>Proxy: Event based call diversion (recursive)
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV AnnServer------------>|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Diversion: Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-200------------------------------------------|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<p>Solution 1a: Non-recursive implementation of call diversion
<br>A possible solution would be to implement the diversion non-recursively:
<br>Proxy: Event based call diversion (non-recursive)
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-302-------------|&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;
|</tt>
<br><tt>|&nbsp; Contact: AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV AnnServer------------------------------->|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-200------------------------------------------|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<p>then the feature interaction could be:
<br>A ignores 302s with Diversion header indicating reason codes for which
A local generation of annoucements.
<br>Proxy: Event based call diversion (non-recursive)
<br>User agent: Event based local announcement (overriding 302s with already
covered Diversion reason codes)
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-302-------------|&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;
|</tt>
<br><tt>|&nbsp; Contact: AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>A generates</tt>
<br><tt>local audio</tt>
<br><tt>indicating</tt>
<br><tt>"The URL you have dialed B...O...B is not in service, please check
the</tt>
<br><tt>&nbsp;URL or dial the operator for assistance."</tt>
<p>Solution 1b: "Supported: annoucements" header
<br>Another possible solution would be for smart UAs (that support announcements)
to use a "Supported: annoucements" header.&nbsp; This supported header
would be used to indicate to proxies that they should not implement event
based call forwarding (for annoucements):
<p>Proxy: Event based call diversion (deferring implementation to UAC when
"Supported: annoucements" is present)
<br>User agent: Event based local announcement
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt</tt>
<br><tt>|&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;
|</tt>
<br><tt>|--INV Bob@B------>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp; Supported: annoucements&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;
|</tt>
<br><tt>|&lt;-404-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;
|</tt>
<br><tt>A generates</tt>
<br><tt>local audio</tt>
<br><tt>indicating</tt>
<br><tt>"The URL you have dialed B...O...B is not in service, please check
the</tt>
<br><tt>&nbsp;URL or dial the operator for assistance."</tt>
<br>&nbsp;
<br>&nbsp;
<p>Desired behavior 2:&nbsp; There should be a mechanism so that announcements
are not billable.
<p>Another issue that has been raised w/r/t annoucements in networks where
SIP signalling is billable.&nbsp; The concern is that in SIP networks where
200 is used to write a start record, implementation of proxy event based
call diversion might generate a charge.
<p>Solution 2a: Play annoucements as early media
<br>One solution that has been proposed is to play annoucements as early
media:
<p>For example, recursively:
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV AnnServer------------>|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Diversion: Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-183------------------------------------------|</tt>
<br><tt>|&nbsp; Content-Disposition: session&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<br><tt>|&lt;-CANCEL---------------------------------------|</tt>
<br><tt>|--200 (CANCEL)-------------------------------->|</tt>
<p>or non-recursively:
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-302-------------|&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;
|</tt>
<br><tt>|&nbsp; Contact: AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV AnnServer------------------------------->|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-183------------------------------------------|</tt>
<br><tt>|&nbsp; Content-Disposition: session&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<br><tt>|&lt;-CANCEL---------------------------------------|</tt>
<br><tt>|--200 (CANCEL)-------------------------------->|</tt>
<p>Solution 2b: Backend billing system is aware of (non-billable) Announcement
Server URL
<br>Another possible solution is that the URL of the AnnServer could be
well-known to the backend billing system and that any accounting records
written connection to the AnnServer would not be billed.
<p>I'd like to solicit others' ideas, problems, and proposed solutions
w/r/t annoucements in SIP.
<p>I'm also looking for co-authors to write an I-D w/r/t announcements.&nbsp;
If interested, please contact me directly at byerly@cisco.com.
<p>thanks for your help,
<br>Bryan
<p>Bryan J. Byerly
<br>byerly@cisco.com
<br>&nbsp;
<br>&nbsp;</blockquote>
</blockquote>

<br>&nbsp;</html>

--------------258BA5EA253D69046A922F03--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 22 15:04:58 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13294
	for <sip-archive@odin.ietf.org>; Mon, 22 Jan 2001 15:04:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B946744372; Mon, 22 Jan 2001 14:05:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by lists.bell-labs.com (Postfix) with ESMTP id 46CC444336
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 14:04:11 -0500 (EST)
Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16])
	by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA26623;
	Mon, 22 Jan 2001 15:03:37 -0500 (EST)
Received: from cisco.com (rtp-ptdxdm1.cisco.com [64.102.17.217])
	by dingdong.cisco.com (Mirapoint)
	with ESMTP id AAL19948 (AUTH byerly);
	Mon, 22 Jan 2001 15:03:56 -0500 (EST)
Message-ID: <3A6C922B.1F4A5FA3@cisco.com>
From: Bryan Byerly <byerly@cisco.com>
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Dinesh Nambisan <dineshn@cisco.com>, sip@lists.bell-labs.com
Cc: byerly@cisco.com
Subject: Re: [SIP] Announcements in SIP
References: <FMEKIFKAGKIKCCGGLCNHKEGGCGAA.dineshn@cisco.com>
Content-Type: multipart/alternative;
 boundary="------------F947203D3A9F98C05F3F477D"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 22 Jan 2001 15:03:55 -0500


--------------F947203D3A9F98C05F3F477D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dinesh Nambisan wrote:

>  Hi Bryan,  had a couple of questions with reference to your proposal;
> how would in-band announcements be handledwhen it is relayed through
> SIP-ISDN (read POTS) gateways ? Typically (atleast in the H.323
> world), when a call isnot end to end ISDN and an announcement needs to
> be played, the far-end switch would use either the "progress"indicator
> in Proceeding/Alerting or would send an Progress msg itself to
> indicate to the call originatorabout presence of inband information
> (in most cases, a tone or an announcement), which is relayed by the
> g/w to the originator. Hence if the voice path has already been setup,
> the originating endpoint is ready to receive in-band media (esp with
> it being told before hand using progress) and the originator hears the
> announcement without a CONNECT beingever sent along the path and
> without the call being billed. In this case, the g/w sending a 200 to
> indicate an announcement seems to break that model, is it not ?

"183" (Session Progress) is the analogous SIP response for Q.931's
"Progress" message.  Both are end-to-end provisional responses.

And, similarly "100" (Trying) is the analogous SIP resposne for Q.931's
"Call Proceeding" message.  Both are hop-by-hop provisional responses.

Thus, it seems that usage of 183 with early media (for
announcements) would mimic preexisting Q.931 behavior.

Is everyone ok with using early media to play annoucements?  Is it safe
to assume that even dumb UAs will support 183 with early media?


> On the other hand, say we dont have a 200 response, the announcements
> therefore are "early-media", am not sure how many endpoints handle
> that to begin with, but one major hole seems to be the case of forking
> proxies: a forking proxy inbetween sends the requests to multiple
> destinations, and in a weird situation which is very much likely, we
> get announcement early media from multiple places !!!

I agree that such weird situations are undesirable.  I think this
particular problem could be addressed operationally.  In order to
prevent such weird situations, I think it seem natural to configure the
"originating" proxy to perform the diversion.  Since the originating
proxy would only send one response upstream normally, the originating
proxy could choose to implement call diversion based upon that one
response he would normally send upstream.
 As long as an/the originating proxy performs the diversion, then we're
ok, right?

thanks for your help,
Bryan
 Cheers,Dinesh-----Original Message-----
From: sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Bryan Byerly
Sent: Monday, January 22, 2001 8:54 AM
To: sip@lists.bell-labs.com
Cc: byerly@cisco.com
Subject: [SIP] Announcements in SIP


     Hi guys,

     I'd like to solicit ideas/consensus w/r/t announcements in
     SIP.

     For this thread of discussion, we're talking about
     announcements which are played when an error occurred during
     call setup.  For instance, on 404, a message could be played
     "The URL you have dialed B...O...B. is not in service, please
     check the URL or dial the operator for assistance".

     There are at least two desired behaviors w/r/t annoucements:
     Desired behavior 1: There should be a mechanism so that local
     annoucements override network annoucements.
     Desired behavior 2: There should be a mechanism so that
     announcements are not billable.

     Like call forwarding features in SIP, there are implementable
     solutions to play annoucements using user agents or proxies.

     In the diagrams below, A, B, and C are user agents, Po is an
     originating proxy and Pt is a terminating proxy.

     User agent: Event based local announcement
     A                 Po             Pt
     |                  |              |
     |--INV Bob@B------>|              |
     |                  |              |
     |<-404-------------|              |
     |                  |              |
     A generates
     local audio
     indicating
     "The URL you have dialed B...O...B is not in service, please
     check the
      URL or dial the operator for assistance."


     Proxy: Event based call diversion (recursive)
     A                  Po             Pt        Announcement
                                                   Server
     |                  |              |             |
     |--INV Bob@B------>|              |             |
     |                  |--INV Bob@B-->|             |
     |                  |<-404---------|             |
     |            proxy implements     |             |
     |            call forward on 404  |             |
     |                  |--INV AnnServer------------>|
     |                  |  Diversion: Bob@B          |
     |                  |              |             |
     |<-200------------------------------------------|
     |<==="The URL you have dialed B...O...B is not==|
     |     in service, please check the URL or dial  |
     |     the operator for assistance"


     Both approaches are viable and there are
     advantages/disadvantages to each.  If all user agents
     supported local generation of announcements, then an event
     based call diversion solution may not be needed.  However, in
     today's world, many user agent implementations do not have
     support for generating local announcements.

     Advantages for "event based local announcements"
     a) requires no network bandwidth
     b) requires no annoucements server

     Disadvantages for "event based local announcements"
     a) Not all SIP user agents support locally generated
     announcements
     b) provisioning issues for large-scale deployments. (i.e. If
     desirable, how would a network admin configure multi-vendor
     SIP phones in his net with certain announcements).

     Advantages for "event based call diversion"
     a) Provides annoucement support in multi-vendor networks
     across all SIP user agents
     b) Provisioning is centralized at proxy and announcement
     server

     Disadvantages for "event based call diversion"
     a) requires network bandwidth to play annoucements
     b) requires presence of an announcements server

     I'm not interested in a holy war of which to use.  Each
     solution will be appropriate for certain network deployments.
     There will soon be implementations of event based local
     annoucements and event based call diversion.  The more
     important issue is to define a mechanism to get desired
     feature interaction.



     Desired behavior 1: There should be a mechanism so that local
     annoucements override network annoucements.

     I would like the behavior that locally generated annoucements
     take precendence over proxy event based call diversion.  In
     other words, given a UA that is configured to play
     announcement X and proxy that is configured to divert to an
     announcement server to play message Y, I want X to be played.
     i.e. I want the behavior of a smart UA to be able to override
     the behavior (provided by proxies in the network) to dumb UAs.

     Unfortunately, Po gets a chance to divert the call first:
     Proxy: Event based call diversion (recursive)
     A                  Po             Pt         AnnServer
     |                  |              |             |
     |--INV Bob@B------>|              |             |
     |                  |--INV Bob@B-->|             |
     |                  |<-404---------|             |
     |            proxy implements     |             |
     |            call forward on 404  |             |
     |                  |--INV AnnServer------------>|
     |                  |  Diversion: Bob@B          |
     |                  |              |             |
     |<-200------------------------------------------|
     |<==="The URL you have dialed B...O...B is not==|
     |     in service, please check the URL or dial  |
     |     the operator for assistance"

     Solution 1a: Non-recursive implementation of call diversion
     A possible solution would be to implement the diversion
     non-recursively:
     Proxy: Event based call diversion (non-recursive)
     A                  Po             Pt         AnnServer
     |                  |              |             |
     |--INV Bob@B------>|              |             |
     |                  |--INV Bob@B-->|             |
     |                  |<-404---------|             |
     |            proxy implements     |             |
     |            non-recursive        |             |
     |            call forward on 404  |             |
     |<-302-------------|              |             |
     |  Contact: AnnServer             |             |
     |  Diversion: Bob@B; reason=404   |             |
     |                  |              |             |
     |--INV AnnServer------------------------------->|
     |  Diversion: Bob@B; reason=404   |             |
     |                  |              |             |
     |<-200------------------------------------------|
     |<==="The URL you have dialed B...O...B is not==|
     |     in service, please check the URL or dial  |
     |     the operator for assistance"

     then the feature interaction could be:
     A ignores 302s with Diversion header indicating reason codes
     for which A local generation of annoucements.
     Proxy: Event based call diversion (non-recursive)
     User agent: Event based local announcement (overriding 302s
     with already covered Diversion reason codes)
     A                  Po             Pt         AnnServer
     |                  |              |             |
     |--INV Bob@B------>|              |             |
     |                  |--INV Bob@B-->|             |
     |                  |<-404---------|             |
     |            proxy implements     |             |
     |            non-recursive        |             |
     |            call forward on 404  |             |
     |<-302-------------|              |             |
     |  Contact: AnnServer             |             |
     |  Diversion: Bob@B; reason=404   |             |
     |                  |              |             |
     A generates
     local audio
     indicating
     "The URL you have dialed B...O...B is not in service, please
     check the
      URL or dial the operator for assistance."

     Solution 1b: "Supported: annoucements" header
     Another possible solution would be for smart UAs (that support
     announcements) to use a "Supported: annoucements" header.
     This supported header would be used to indicate to proxies
     that they should not implement event based call forwarding
     (for annoucements):

     Proxy: Event based call diversion (deferring implementation to
     UAC when "Supported: annoucements" is present)
     User agent: Event based local announcement
     A                 Po             Pt
     |                  |              |
     |--INV Bob@B------>|              |
     |  Supported: annoucements        |
     |                  |              |
     |<-404-------------|              |
     |                  |              |
     A generates
     local audio
     indicating
     "The URL you have dialed B...O...B is not in service, please
     check the
      URL or dial the operator for assistance."



     Desired behavior 2:  There should be a mechanism so that
     announcements are not billable.

     Another issue that has been raised w/r/t annoucements in
     networks where SIP signalling is billable.  The concern is
     that in SIP networks where 200 is used to write a start
     record, implementation of proxy event based call diversion
     might generate a charge.

     Solution 2a: Play annoucements as early media
     One solution that has been proposed is to play annoucements as
     early media:

     For example, recursively:
     A                  Po             Pt         AnnServer
     |                  |              |             |
     |--INV Bob@B------>|              |             |
     |                  |--INV Bob@B-->|             |
     |                  |<-404---------|             |
     |            proxy implements     |             |
     |            call forward on 404  |             |
     |                  |--INV AnnServer------------>|
     |                  |  Diversion: Bob@B          |
     |                  |              |             |
     |<-183------------------------------------------|
     |  Content-Disposition: session                 |
     |<==="The URL you have dialed B...O...B is not==|
     |     in service, please check the URL or dial  |
     |     the operator for assistance"
     |<-CANCEL---------------------------------------|
     |--200 (CANCEL)-------------------------------->|

     or non-recursively:
     A                  Po             Pt         AnnServer
     |                  |              |             |
     |--INV Bob@B------>|              |             |
     |                  |--INV Bob@B-->|             |
     |                  |<-404---------|             |
     |            proxy implements     |             |
     |            non-recursive        |             |
     |            call forward on 404  |             |
     |<-302-------------|              |             |
     |  Contact: AnnServer             |             |
     |  Diversion: Bob@B; reason=404   |             |
     |                  |              |             |
     |--INV AnnServer------------------------------->|
     |  Diversion: Bob@B; reason=404   |             |
     |                  |              |             |
     |<-183------------------------------------------|
     |  Content-Disposition: session                 |
     |<==="The URL you have dialed B...O...B is not==|
     |     in service, please check the URL or dial  |
     |     the operator for assistance"
     |<-CANCEL---------------------------------------|
     |--200 (CANCEL)-------------------------------->|

     Solution 2b: Backend billing system is aware of (non-billable)
     Announcement Server URL
     Another possible solution is that the URL of the AnnServer
     could be well-known to the backend billing system and that any
     accounting records written connection to the AnnServer would
     not be billed.

     I'd like to solicit others' ideas, problems, and proposed
     solutions w/r/t annoucements in SIP.

     I'm also looking for co-authors to write an I-D w/r/t
     announcements.  If interested, please contact me directly at
     byerly@cisco.com.

     thanks for your help,
     Bryan

     Bryan J. Byerly
     byerly@cisco.com






--------------F947203D3A9F98C05F3F477D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Dinesh Nambisan wrote:
<blockquote TYPE=CITE>&nbsp;<span class=995294117-22012001><font face="Arial"><font color="#0000FF"><font size=-1>Hi
Bryan,</font></font></font></span><span class=995294117-22012001><font face="Arial"><font color="#0000FF"><font size=-1>&nbsp;
had a couple of questions with reference to your proposal; how would in-band
announcements be handled</font></font></font></span><span class=995294117-22012001><font face="Arial"><font color="#0000FF"><font size=-1>when
it is relayed through SIP-ISDN (read POTS) gateways ? Typically (atleast
in the H.323 world), when a call is</font></font></font></span><span class=995294117-22012001><font face="Arial"><font color="#0000FF"><font size=-1>not
end to end ISDN and an announcement needs to be played, the far-end switch
would use either the "progress"</font></font></font></span><span 
class=995294117-22012001><font face="Arial"><font color="#0000FF"><font size=-1>indicator
in Proceeding/Alerting or would send an Progress msg itself to indicate
to the call originator</font></font></font></span><span class=995294117-22012001><font face="Arial"><font color="#0000FF"><font size=-1>about
presence of inband information (in most cases, a tone or an announcement),
which is relayed by the g/w to the originator. Hence if the voice path&nbsp;</span><span 
class=995294117-22012001>has
already been setup, the originating endpoint is ready to receive in-band
media (esp with it being told&nbsp;</span><span class=995294117-22012001>before
hand using progress) and the originator hears the announcement without
a CONNECT being</font></font></font></span><span class=995294117-22012001><font face="Arial"><font color="#0000FF"><font size=-1>ever
sent along the path and without the call being billed. In this case, the
g/w sending a 200 to indicate an announcement seems to break that model,
is it not ?</font></font></font></span></blockquote>
"183" (Session Progress) is the analogous SIP response for Q.931's "Progress"&nbsp;message.&nbsp;
Both are end-to-end provisional responses.
<p>And, similarly "100" (Trying) is the analogous SIP&nbsp;resposne for
Q.931's "Call Proceeding" message.&nbsp; Both are hop-by-hop provisional
responses.
<p>Thus, it seems that usage of 183 with early media (for announcements)&nbsp;would
mimic preexisting Q.931 behavior.
<p>Is everyone ok with using early media to play annoucements?&nbsp; Is
it safe to assume that even dumb UAs will support 183 with early media?
<br>&nbsp;
<blockquote TYPE=CITE><span class=995294117-22012001><font face="Arial"><font color="#0000FF"><font size=-1>On
the other hand, say we dont have a 200 response, the announcements therefore
are "early-media", am not sure how many endpoints handle that to begin
with, but one major hole seems to be the case of forking proxies: a forking
proxy in</font></font></font></span><span 
class=995294117-22012001><font face="Arial"><font color="#0000FF"><font size=-1>between
sends the requests to multiple destinations, and in a weird situation which
is very much likely, we get announcement early&nbsp;</span><span 
class=995294117-22012001>media
from multiple places !!!</font></font></font></span></blockquote>

<p><br>I&nbsp;agree that such weird situations are undesirable.&nbsp; I&nbsp;think
this particular problem could be addressed operationally.&nbsp; In order
to prevent such weird situations, I think it seem natural to configure
the "originating" proxy to perform the diversion.&nbsp; Since the originating
proxy would only send one response upstream normally, the originating proxy
could choose to implement call diversion based upon that one response he
would normally send upstream.
<br>&nbsp;As long as an/the originating proxy performs the diversion, then
we're ok, right?
<p>thanks for your help,
<br>Bryan
<br>&nbsp;<span 
class=995294117-22012001><font face="Arial"><font color="#0000FF"><font size=-1>Cheers,</font></font></font></span><span 
class=995294117-22012001><font face="Arial"><font color="#0000FF"><font size=-1>Dinesh</font></font></font></span><span 
class=995294117-22012001></span><span 
class=995294117-22012001></span><span 
class=995294117-22012001></span><span 
class=995294117-22012001></span><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> sip-admin@lists.bell-labs.com
[<A HREF="mailto:sip-admin@lists.bell-labs.com">mailto:sip-admin@lists.bell-labs.com</A>]<b>On Behalf Of </b>Bryan Byerly</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Monday, January 22,
2001 8:54 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> sip@lists.bell-labs.com</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> byerly@cisco.com</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> [SIP] Announcements
in SIP</font></font>
<br>&nbsp;
<blockquote style="MARGIN-RIGHT: 0px">Hi guys,
<p>I'd like to solicit ideas/consensus w/r/t announcements in SIP.
<p>For this thread of discussion, we're talking about announcements which
are played when an error occurred during call setup.&nbsp; For instance,
on 404, a message could be played "The URL you have dialed B...O...B. is
not in service, please check the URL or dial the operator for assistance".
<p>There are at least two desired behaviors w/r/t annoucements:
<br>Desired behavior 1: There should be a mechanism so that local annoucements
override network annoucements.
<br>Desired behavior 2: There should be a mechanism so that announcements
are not billable.
<p>Like call forwarding features in SIP, there are implementable solutions
to play annoucements using user agents or proxies.
<p>In the diagrams below, A, B, and C are user agents, Po is an originating
proxy and Pt is a terminating proxy.
<p>User agent: Event based local announcement
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt</tt>
<br><tt>|&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;
|</tt>
<br><tt>|--INV Bob@B------>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;
|</tt>
<br><tt>|&lt;-404-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;
|</tt>
<br><tt>A generates</tt>
<br><tt>local audio</tt>
<br><tt>indicating</tt>
<br><tt>"The URL you have dialed B...O...B is not in service, please check
the</tt>
<br><tt>&nbsp;URL or dial the operator for assistance."</tt>
<br>&nbsp;
<p>Proxy: Event based call diversion (recursive)
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Announcement</tt>
<br><tt>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Server</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV AnnServer------------>|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Diversion: Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-200------------------------------------------|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<br>&nbsp;
<p>Both approaches are viable and there are advantages/disadvantages to
each.&nbsp; If all user agents supported local generation of announcements,
then an event based call diversion solution may not be needed.&nbsp; However,
in today's world, many user agent implementations do not have support for
generating local announcements.
<p>Advantages for "event based local announcements"
<br>a) requires no network bandwidth
<br>b) requires no annoucements server
<p>Disadvantages for "event based local announcements"
<br>a) Not all SIP user agents support locally generated announcements
<br>b) provisioning issues for large-scale deployments. (i.e. If desirable,
how would a network admin configure multi-vendor SIP phones in his net
with certain announcements).
<p>Advantages for "event based call diversion"
<br>a) Provides annoucement support in multi-vendor networks across all
SIP user agents
<br>b) Provisioning is centralized at proxy and announcement server
<p>Disadvantages for "event based call diversion"
<br>a) requires network bandwidth to play annoucements
<br>b) requires presence of an announcements server
<p>I'm not interested in a holy war of which to use.&nbsp; Each solution
will be appropriate for certain network deployments.&nbsp; There will soon
be implementations of event based local annoucements and event based call
diversion.&nbsp; The more important issue is to define a mechanism to get
desired feature interaction.
<br>&nbsp;
<br>&nbsp;
<p>Desired behavior 1: There should be a mechanism so that local annoucements
override network annoucements.
<p>I would like the behavior that locally generated annoucements take precendence
over proxy event based call diversion.&nbsp; In other words, given a UA
that is configured to play announcement X and proxy that is configured
to divert to an announcement server to play message Y, I want X to be played.&nbsp;
i.e. I want the behavior of a smart UA to be able to override the behavior
(provided by proxies in the network) to dumb UAs.
<p>Unfortunately, Po gets a chance to divert the call first:
<br>Proxy: Event based call diversion (recursive)
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV AnnServer------------>|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Diversion: Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-200------------------------------------------|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<p>Solution 1a: Non-recursive implementation of call diversion
<br>A possible solution would be to implement the diversion non-recursively:
<br>Proxy: Event based call diversion (non-recursive)
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-302-------------|&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;
|</tt>
<br><tt>|&nbsp; Contact: AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV AnnServer------------------------------->|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-200------------------------------------------|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<p>then the feature interaction could be:
<br>A ignores 302s with Diversion header indicating reason codes for which
A local generation of annoucements.
<br>Proxy: Event based call diversion (non-recursive)
<br>User agent: Event based local announcement (overriding 302s with already
covered Diversion reason codes)
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-302-------------|&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;
|</tt>
<br><tt>|&nbsp; Contact: AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>A generates</tt>
<br><tt>local audio</tt>
<br><tt>indicating</tt>
<br><tt>"The URL you have dialed B...O...B is not in service, please check
the</tt>
<br><tt>&nbsp;URL or dial the operator for assistance."</tt>
<p>Solution 1b: "Supported: annoucements" header
<br>Another possible solution would be for smart UAs (that support announcements)
to use a "Supported: annoucements" header.&nbsp; This supported header
would be used to indicate to proxies that they should not implement event
based call forwarding (for annoucements):
<p>Proxy: Event based call diversion (deferring implementation to UAC when
"Supported: annoucements" is present)
<br>User agent: Event based local announcement
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt</tt>
<br><tt>|&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;
|</tt>
<br><tt>|--INV Bob@B------>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp; Supported: annoucements&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;
|</tt>
<br><tt>|&lt;-404-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;
|</tt>
<br><tt>A generates</tt>
<br><tt>local audio</tt>
<br><tt>indicating</tt>
<br><tt>"The URL you have dialed B...O...B is not in service, please check
the</tt>
<br><tt>&nbsp;URL or dial the operator for assistance."</tt>
<br>&nbsp;
<br>&nbsp;
<p>Desired behavior 2:&nbsp; There should be a mechanism so that announcements
are not billable.
<p>Another issue that has been raised w/r/t annoucements in networks where
SIP signalling is billable.&nbsp; The concern is that in SIP networks where
200 is used to write a start record, implementation of proxy event based
call diversion might generate a charge.
<p>Solution 2a: Play annoucements as early media
<br>One solution that has been proposed is to play annoucements as early
media:
<p>For example, recursively:
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV AnnServer------------>|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Diversion: Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-183------------------------------------------|</tt>
<br><tt>|&nbsp; Content-Disposition: session&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<br><tt>|&lt;-CANCEL---------------------------------------|</tt>
<br><tt>|--200 (CANCEL)-------------------------------->|</tt>
<p>or non-recursively:
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-302-------------|&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;
|</tt>
<br><tt>|&nbsp; Contact: AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV AnnServer------------------------------->|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-183------------------------------------------|</tt>
<br><tt>|&nbsp; Content-Disposition: session&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<br><tt>|&lt;-CANCEL---------------------------------------|</tt>
<br><tt>|--200 (CANCEL)-------------------------------->|</tt>
<p>Solution 2b: Backend billing system is aware of (non-billable) Announcement
Server URL
<br>Another possible solution is that the URL of the AnnServer could be
well-known to the backend billing system and that any accounting records
written connection to the AnnServer would not be billed.
<p>I'd like to solicit others' ideas, problems, and proposed solutions
w/r/t annoucements in SIP.
<p>I'm also looking for co-authors to write an I-D w/r/t announcements.&nbsp;
If interested, please contact me directly at byerly@cisco.com.
<p>thanks for your help,
<br>Bryan
<p>Bryan J. Byerly
<br>byerly@cisco.com</blockquote>

<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;</html>

--------------F947203D3A9F98C05F3F477D--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 22 15:26:56 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13596
	for <sip-archive@odin.ietf.org>; Mon, 22 Jan 2001 15:26:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 60DD94437C; Mon, 22 Jan 2001 14:27:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from rainier.illuminet.com (unknown [63.116.20.4])
	by lists.bell-labs.com (Postfix) with ESMTP id 3390A4436C
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 14:26:13 -0500 (EST)
Received: from olwinexsmtp01.corp.illuminet.com ([172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id MAA09188 for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 12:25:59 -0800 (PST)
Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19)
	id <CYRAYSJL>; Mon, 22 Jan 2001 12:25:56 -0800
Message-ID: <1C1EEC765F843E44996971A80682118B2523E7@OPWINEXCL01>
From: Kevin McCandless <KMcCandless@illuminet.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Routing of SIP calls
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 22 Jan 2001 12:25:16 -0800

Hello Everyone:

Can someone explain these two routing scenarios of SIP calls for me.  

1.  The first would be SIP1 calls SIP2 and neither party has moved.  In this
example, how does SIP1 find SIP2?   

2.  The second would be SIP1 calls SIP2 but SIP2 has moved.  In this
example, how does SIP1 find SIP2?   

Also, would the ENUM proposed databases be involved in the routing for
either scenario?

Sincerely,

Kevin McCandless
Senior Network Planner
Illuminet
913-814-6397
kmccandles@illuminet.com


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 22 15:32:58 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13750
	for <sip-archive@odin.ietf.org>; Mon, 22 Jan 2001 15:32:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7D24444384; Mon, 22 Jan 2001 14:33:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by lists.bell-labs.com (Postfix) with ESMTP id E7FA044383
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 14:31:59 -0500 (EST)
Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id MAA19479;
	Mon, 22 Jan 2001 12:31:41 -0800 (PST)
Received: from dineshnlap (dhcp-171-69-85-87.cisco.com [171.69.85.87])
	by mira-sjcd-1.cisco.com (Mirapoint)
	with SMTP id AFB04186;
	Mon, 22 Jan 2001 12:31:36 -0800 (PST)
Reply-To: <dineshn@cisco.com>
From: "Dinesh Nambisan" <dineshn@cisco.com>
To: <byerly@cisco.com>, <sip@lists.bell-labs.com>
Subject: RE: [SIP] Announcements in SIP
Message-ID: <NEBBIHMINKJLJPFOPBGKEELHCHAA.dineshn@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001D_01C0846E.80A8F7C0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3A6C922B.1F4A5FA3@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 22 Jan 2001 12:26:10 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_001D_01C0846E.80A8F7C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Billy Biggs had outlined a whole set of problems with early media in one of
his earlier emails; see
http://lists.bell-labs.com/pipermail/sip/2000q4/004141.html
Looks like there is a definite problem which needs to be resolved, to
maintain interop with existing public infrastructure support of early media
is unavoidable,
but existing proxy behaviour in coordination with early media can create a
few problems, just curious, have there been any attempts to iron this out ?
/Dinesh
  -----Original Message-----
  From: byerly@cisco.com [mailto:byerly@cisco.com]
  Sent: Monday, January 22, 2001 12:04 PM
  To: Dinesh Nambisan; sip@lists.bell-labs.com
  Cc: byerly@cisco.com
  Subject: Re: [SIP] Announcements in SIP


  Dinesh Nambisan wrote:
     Hi Bryan,  had a couple of questions with reference to your proposal;
how would in-band announcements be handledwhen it is relayed through
SIP-ISDN (read POTS) gateways ? Typically (atleast in the H.323 world), when
a call isnot end to end ISDN and an announcement needs to be played, the
far-end switch would use either the "progress"indicator in
Proceeding/Alerting or would send an Progress msg itself to indicate to the
call originatorabout presence of inband information (in most cases, a tone
or an announcement), which is relayed by the g/w to the originator. Hence if
the voice path has already been setup, the originating endpoint is ready to
receive in-band media (esp with it being told before hand using progress)
and the originator hears the announcement without a CONNECT beingever sent
along the path and without the call being billed. In this case, the g/w
sending a 200 to indicate an announcement seems to break that model, is it
not ?
  "183" (Session Progress) is the analogous SIP response for Q.931's
"Progress" message.  Both are end-to-end provisional responses.
  And, similarly "100" (Trying) is the analogous SIP resposne for Q.931's
"Call Proceeding" message.  Both are hop-by-hop provisional responses.

  Thus, it seems that usage of 183 with early media (for announcements)
would mimic preexisting Q.931 behavior.

  Is everyone ok with using early media to play annoucements?  Is it safe to
assume that even dumb UAs will support 183 with early media?


    On the other hand, say we dont have a 200 response, the announcements
therefore are "early-media", am not sure how many endpoints handle that to
begin with, but one major hole seems to be the case of forking proxies: a
forking proxy inbetween sends the requests to multiple destinations, and in
a weird situation which is very much likely, we get announcement early media
from multiple places !!!

  I agree that such weird situations are undesirable.  I think this
particular problem could be addressed operationally.  In order to prevent
such weird situations, I think it seem natural to configure the
"originating" proxy to perform the diversion.  Since the originating proxy
would only send one response upstream normally, the originating proxy could
choose to implement call diversion based upon that one response he would
normally send upstream.
   As long as an/the originating proxy performs the diversion, then we're
ok, right?

  thanks for your help,
  Bryan
   Cheers,Dinesh-----Original Message-----
  From: sip-admin@lists.bell-labs.com
[mailto:sip-admin@lists.bell-labs.com]On Behalf Of Bryan Byerly
  Sent: Monday, January 22, 2001 8:54 AM
  To: sip@lists.bell-labs.com
  Cc: byerly@cisco.com
  Subject: [SIP] Announcements in SIP


    Hi guys,
    I'd like to solicit ideas/consensus w/r/t announcements in SIP.

    For this thread of discussion, we're talking about announcements which
are played when an error occurred during call setup.  For instance, on 404,
a message could be played "The URL you have dialed B...O...B. is not in
service, please check the URL or dial the operator for assistance".

    There are at least two desired behaviors w/r/t annoucements:
    Desired behavior 1: There should be a mechanism so that local
annoucements override network annoucements.
    Desired behavior 2: There should be a mechanism so that announcements
are not billable.

    Like call forwarding features in SIP, there are implementable solutions
to play annoucements using user agents or proxies.

    In the diagrams below, A, B, and C are user agents, Po is an originating
proxy and Pt is a terminating proxy.

    User agent: Event based local announcement
    A                 Po             Pt
    |                  |              |
    |--INV Bob@B------>|              |
    |                  |              |
    |<-404-------------|              |
    |                  |              |
    A generates
    local audio
    indicating
    "The URL you have dialed B...O...B is not in service, please check the
     URL or dial the operator for assistance."


    Proxy: Event based call diversion (recursive)
    A                  Po             Pt        Announcement
                                                  Server
    |                  |              |             |
    |--INV Bob@B------>|              |             |
    |                  |--INV Bob@B-->|             |
    |                  |<-404---------|             |
    |            proxy implements     |             |
    |            call forward on 404  |             |
    |                  |--INV AnnServer------------>|
    |                  |  Diversion: Bob@B          |
    |                  |              |             |
    |<-200------------------------------------------|
    |<==="The URL you have dialed B...O...B is not==|
    |     in service, please check the URL or dial  |
    |     the operator for assistance"


    Both approaches are viable and there are advantages/disadvantages to
each.  If all user agents supported local generation of announcements, then
an event based call diversion solution may not be needed.  However, in
today's world, many user agent implementations do not have support for
generating local announcements.

    Advantages for "event based local announcements"
    a) requires no network bandwidth
    b) requires no annoucements server

    Disadvantages for "event based local announcements"
    a) Not all SIP user agents support locally generated announcements
    b) provisioning issues for large-scale deployments. (i.e. If desirable,
how would a network admin configure multi-vendor SIP phones in his net with
certain announcements).

    Advantages for "event based call diversion"
    a) Provides annoucement support in multi-vendor networks across all SIP
user agents
    b) Provisioning is centralized at proxy and announcement server

    Disadvantages for "event based call diversion"
    a) requires network bandwidth to play annoucements
    b) requires presence of an announcements server

    I'm not interested in a holy war of which to use.  Each solution will be
appropriate for certain network deployments.  There will soon be
implementations of event based local annoucements and event based call
diversion.  The more important issue is to define a mechanism to get desired
feature interaction.



    Desired behavior 1: There should be a mechanism so that local
annoucements override network annoucements.

    I would like the behavior that locally generated annoucements take
precendence over proxy event based call diversion.  In other words, given a
UA that is configured to play announcement X and proxy that is configured to
divert to an announcement server to play message Y, I want X to be played.
i.e. I want the behavior of a smart UA to be able to override the behavior
(provided by proxies in the network) to dumb UAs.

    Unfortunately, Po gets a chance to divert the call first:
    Proxy: Event based call diversion (recursive)
    A                  Po             Pt         AnnServer
    |                  |              |             |
    |--INV Bob@B------>|              |             |
    |                  |--INV Bob@B-->|             |
    |                  |<-404---------|             |
    |            proxy implements     |             |
    |            call forward on 404  |             |
    |                  |--INV AnnServer------------>|
    |                  |  Diversion: Bob@B          |
    |                  |              |             |
    |<-200------------------------------------------|
    |<==="The URL you have dialed B...O...B is not==|
    |     in service, please check the URL or dial  |
    |     the operator for assistance"

    Solution 1a: Non-recursive implementation of call diversion
    A possible solution would be to implement the diversion non-recursively:
    Proxy: Event based call diversion (non-recursive)
    A                  Po             Pt         AnnServer
    |                  |              |             |
    |--INV Bob@B------>|              |             |
    |                  |--INV Bob@B-->|             |
    |                  |<-404---------|             |
    |            proxy implements     |             |
    |            non-recursive        |             |
    |            call forward on 404  |             |
    |<-302-------------|              |             |
    |  Contact: AnnServer             |             |
    |  Diversion: Bob@B; reason=404   |             |
    |                  |              |             |
    |--INV AnnServer------------------------------->|
    |  Diversion: Bob@B; reason=404   |             |
    |                  |              |             |
    |<-200------------------------------------------|
    |<==="The URL you have dialed B...O...B is not==|
    |     in service, please check the URL or dial  |
    |     the operator for assistance"

    then the feature interaction could be:
    A ignores 302s with Diversion header indicating reason codes for which A
local generation of annoucements.
    Proxy: Event based call diversion (non-recursive)
    User agent: Event based local announcement (overriding 302s with already
covered Diversion reason codes)
    A                  Po             Pt         AnnServer
    |                  |              |             |
    |--INV Bob@B------>|              |             |
    |                  |--INV Bob@B-->|             |
    |                  |<-404---------|             |
    |            proxy implements     |             |
    |            non-recursive        |             |
    |            call forward on 404  |             |
    |<-302-------------|              |             |
    |  Contact: AnnServer             |             |
    |  Diversion: Bob@B; reason=404   |             |
    |                  |              |             |
    A generates
    local audio
    indicating
    "The URL you have dialed B...O...B is not in service, please check the
     URL or dial the operator for assistance."

    Solution 1b: "Supported: annoucements" header
    Another possible solution would be for smart UAs (that support
announcements) to use a "Supported: annoucements" header.  This supported
header would be used to indicate to proxies that they should not implement
event based call forwarding (for annoucements):

    Proxy: Event based call diversion (deferring implementation to UAC when
"Supported: annoucements" is present)
    User agent: Event based local announcement
    A                 Po             Pt
    |                  |              |
    |--INV Bob@B------>|              |
    |  Supported: annoucements        |
    |                  |              |
    |<-404-------------|              |
    |                  |              |
    A generates
    local audio
    indicating
    "The URL you have dialed B...O...B is not in service, please check the
     URL or dial the operator for assistance."



    Desired behavior 2:  There should be a mechanism so that announcements
are not billable.

    Another issue that has been raised w/r/t annoucements in networks where
SIP signalling is billable.  The concern is that in SIP networks where 200
is used to write a start record, implementation of proxy event based call
diversion might generate a charge.

    Solution 2a: Play annoucements as early media
    One solution that has been proposed is to play annoucements as early
media:

    For example, recursively:
    A                  Po             Pt         AnnServer
    |                  |              |             |
    |--INV Bob@B------>|              |             |
    |                  |--INV Bob@B-->|             |
    |                  |<-404---------|             |
    |            proxy implements     |             |
    |            call forward on 404  |             |
    |                  |--INV AnnServer------------>|
    |                  |  Diversion: Bob@B          |
    |                  |              |             |
    |<-183------------------------------------------|
    |  Content-Disposition: session                 |
    |<==="The URL you have dialed B...O...B is not==|
    |     in service, please check the URL or dial  |
    |     the operator for assistance"
    |<-CANCEL---------------------------------------|
    |--200 (CANCEL)-------------------------------->|

    or non-recursively:
    A                  Po             Pt         AnnServer
    |                  |              |             |
    |--INV Bob@B------>|              |             |
    |                  |--INV Bob@B-->|             |
    |                  |<-404---------|             |
    |            proxy implements     |             |
    |            non-recursive        |             |
    |            call forward on 404  |             |
    |<-302-------------|              |             |
    |  Contact: AnnServer             |             |
    |  Diversion: Bob@B; reason=404   |             |
    |                  |              |             |
    |--INV AnnServer------------------------------->|
    |  Diversion: Bob@B; reason=404   |             |
    |                  |              |             |
    |<-183------------------------------------------|
    |  Content-Disposition: session                 |
    |<==="The URL you have dialed B...O...B is not==|
    |     in service, please check the URL or dial  |
    |     the operator for assistance"
    |<-CANCEL---------------------------------------|
    |--200 (CANCEL)-------------------------------->|

    Solution 2b: Backend billing system is aware of (non-billable)
Announcement Server URL
    Another possible solution is that the URL of the AnnServer could be
well-known to the backend billing system and that any accounting records
written connection to the AnnServer would not be billed.

    I'd like to solicit others' ideas, problems, and proposed solutions
w/r/t annoucements in SIP.

    I'm also looking for co-authors to write an I-D w/r/t announcements.  If
interested, please contact me directly at byerly@cisco.com.

    thanks for your help,
    Bryan

    Bryan J. Byerly
    byerly@cisco.com







------=_NextPart_000_001D_01C0846E.80A8F7C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D769331120-22012001>Billy=20
Biggs had outlined a whole set of problems with early media in one of =
his=20
earlier emails; see </SPAN></FONT><FONT face=3DArial color=3D#0000ff =
size=3D2><A=20
href=3D"http://lists.bell-labs.com/pipermail/sip/2000q4/004141.html">http=
://lists.bell-labs.com/pipermail/sip/2000q4/004141.html</A></FONT></DIV>
<DIV><SPAN class=3D769331120-22012001><FONT face=3DArial color=3D#0000ff =
size=3D2>Looks=20
like there is a definite problem which needs to be resolved, to maintain =
interop=20
with existing public infrastructure support of early media is =
unavoidable,=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D769331120-22012001><FONT face=3DArial color=3D#0000ff =

size=3D2>but&nbsp;existing proxy behaviour in coordination with early =
media can=20
create a few problems, just curious, have there been any attempts to =
iron this=20
out ?</FONT></SPAN></DIV>
<DIV><SPAN class=3D769331120-22012001><FONT face=3DArial color=3D#0000ff =

size=3D2>/Dinesh</FONT></SPAN></DIV>
<BLOCKQUOTE>
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> byerly@cisco.com=20
  [mailto:byerly@cisco.com]<BR><B>Sent:</B> Monday, January 22, 2001 =
12:04=20
  PM<BR><B>To:</B> Dinesh Nambisan; =
sip@lists.bell-labs.com<BR><B>Cc:</B>=20
  byerly@cisco.com<BR><B>Subject:</B> Re: [SIP] Announcements in=20
  SIP<BR><BR></FONT></DIV>Dinesh Nambisan wrote:=20
  <BLOCKQUOTE TYPE=3D"CITE">&nbsp;<SPAN class=3D995294117-22012001><FONT =

    face=3DArial><FONT color=3D#0000ff><FONT size=3D-1>Hi=20
    Bryan,</FONT></FONT></FONT></SPAN><SPAN =
class=3D995294117-22012001><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D-1>&nbsp; had a =
couple of=20
    questions with reference to your proposal; how would in-band =
announcements=20
    be handled</FONT></FONT></FONT></SPAN><SPAN =
class=3D995294117-22012001><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D-1>when it is =
relayed through=20
    SIP-ISDN (read POTS) gateways ? Typically (atleast in the H.323 =
world), when=20
    a call is</FONT></FONT></FONT></SPAN><SPAN =
class=3D995294117-22012001><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D-1>not end to end =
ISDN and an=20
    announcement needs to be played, the far-end switch would use either =
the=20
    "progress"</FONT></FONT></FONT></SPAN><SPAN =
class=3D995294117-22012001><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D-1>indicator in=20
    Proceeding/Alerting or would send an Progress msg itself to indicate =
to the=20
    call originator</FONT></FONT></FONT></SPAN><SPAN=20
    class=3D995294117-22012001><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
    size=3D-1>about presence of inband information (in most cases, a =
tone or an=20
    announcement), which is relayed by the g/w to the originator. Hence =
if the=20
    voice path&nbsp;</SPAN><SPAN class=3D995294117-22012001>has already =
been=20
    setup, the originating endpoint is ready to receive in-band media =
(esp with=20
    it being told&nbsp;</SPAN><SPAN class=3D995294117-22012001>before =
hand using=20
    progress) and the originator hears the announcement without a =
CONNECT=20
    being</FONT></FONT></FONT></SPAN><SPAN =
class=3D995294117-22012001><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D-1>ever sent along =
the path and=20
    without the call being billed. In this case, the g/w sending a 200 =
to=20
    indicate an announcement seems to break that model, is it not=20
    ?</FONT></FONT></FONT></SPAN></BLOCKQUOTE>"183" (Session Progress) =
is the=20
  analogous SIP response for Q.931's "Progress"&nbsp;message.&nbsp; Both =
are=20
  end-to-end provisional responses.=20
  <P>And, similarly "100" (Trying) is the analogous SIP&nbsp;resposne =
for=20
  Q.931's "Call Proceeding" message.&nbsp; Both are hop-by-hop =
provisional=20
  responses.=20
  <P>Thus, it seems that usage of 183 with early media (for=20
  announcements)&nbsp;would mimic preexisting Q.931 behavior.=20
  <P>Is everyone ok with using early media to play annoucements?&nbsp; =
Is it=20
  safe to assume that even dumb UAs will support 183 with early media?=20
  <BR>&nbsp;=20
  <BLOCKQUOTE TYPE=3D"CITE"><SPAN class=3D995294117-22012001><FONT=20
    face=3DArial><FONT color=3D#0000ff><FONT size=3D-1>On the other =
hand, say we dont=20
    have a 200 response, the announcements therefore are "early-media", =
am not=20
    sure how many endpoints handle that to begin with, but one major =
hole seems=20
    to be the case of forking proxies: a forking proxy=20
    in</FONT></FONT></FONT></SPAN><SPAN class=3D995294117-22012001><FONT =

    face=3DArial><FONT color=3D#0000ff><FONT size=3D-1>between sends the =
requests to=20
    multiple destinations, and in a weird situation which is very much =
likely,=20
    we get announcement early&nbsp;</SPAN><SPAN =
class=3D995294117-22012001>media=20
    from multiple places !!!</FONT></FONT></FONT></SPAN></BLOCKQUOTE>
  <P><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial color=3D#0000ff=20
  size=3D2></FONT><BR>I&nbsp;agree that such weird situations are=20
  undesirable.&nbsp; I&nbsp;think this particular problem could be =
addressed=20
  operationally.&nbsp; In order to prevent such weird situations, I =
think it=20
  seem natural to configure the "originating" proxy to perform the=20
  diversion.&nbsp; Since the originating proxy would only send one =
response=20
  upstream normally, the originating proxy could choose to implement =
call=20
  diversion based upon that one response he would normally send =
upstream.=20
  <BR>&nbsp;As long as an/the originating proxy performs the diversion, =
then=20
  we're ok, right?=20
  <P>thanks for your help, <BR>Bryan <BR>&nbsp;<SPAN=20
  class=3D995294117-22012001><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D-1>Cheers,</FONT></FONT></FONT></SPAN><SPAN=20
  class=3D995294117-22012001><FONT face=3DArial><FONT =
color=3D#0000ff><FONT=20
  size=3D-1>Dinesh</FONT></FONT></FONT></SPAN><SPAN=20
  class=3D995294117-22012001></SPAN><SPAN =
class=3D995294117-22012001></SPAN><SPAN=20
  class=3D995294117-22012001></SPAN><SPAN =
class=3D995294117-22012001></SPAN><FONT=20
  face=3DTahoma><FONT size=3D-1>-----Original Message-----</FONT></FONT> =
<BR><FONT=20
  face=3DTahoma><FONT size=3D-1><B>From:</B> =
sip-admin@lists.bell-labs.com [<A=20
  =
href=3D"mailto:sip-admin@lists.bell-labs.com">mailto:sip-admin@lists.bell=
-labs.com</A>]<B>On=20
  Behalf Of </B>Bryan Byerly</FONT></FONT> <BR><FONT face=3DTahoma><FONT =

  size=3D-1><B>Sent:</B> Monday, January 22, 2001 8:54 AM</FONT></FONT> =
<BR><FONT=20
  face=3DTahoma><FONT size=3D-1><B>To:</B> =
sip@lists.bell-labs.com</FONT></FONT>=20
  <BR><FONT face=3DTahoma><FONT size=3D-1><B>Cc:</B> =
byerly@cisco.com</FONT></FONT>=20
  <BR><FONT face=3DTahoma><FONT size=3D-1><B>Subject:</B> [SIP] =
Announcements in=20
  SIP</FONT></FONT> <BR>&nbsp;=20
  <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px">Hi guys,=20
    <P>I'd like to solicit ideas/consensus w/r/t announcements in SIP.=20
    <P>For this thread of discussion, we're talking about announcements =
which=20
    are played when an error occurred during call setup.&nbsp; For =
instance, on=20
    404, a message could be played "The URL you have dialed B...O...B. =
is not in=20
    service, please check the URL or dial the operator for assistance".=20
    <P>There are at least two desired behaviors w/r/t annoucements: =
<BR>Desired=20
    behavior 1: There should be a mechanism so that local annoucements =
override=20
    network annoucements. <BR>Desired behavior 2: There should be a =
mechanism so=20
    that announcements are not billable.=20
    <P>Like call forwarding features in SIP, there are implementable =
solutions=20
    to play annoucements using user agents or proxies.=20
    <P>In the diagrams below, A, B, and C are user agents, Po is an =
originating=20
    proxy and Pt is a terminating proxy.=20
    <P>User agent: Event based local announcement=20
    =
<BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
    Pt</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    |</TT> <BR><TT>|--INV=20
    =
Bob@B------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    |</TT>=20
    =
<BR><TT>|&lt;-404-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    |</TT> <BR><TT>A generates</TT> <BR><TT>local audio</TT>=20
    <BR><TT>indicating</TT> <BR><TT>"The URL you have dialed B...O...B =
is not in=20
    service, please check the</TT> <BR><TT>&nbsp;URL or dial the =
operator for=20
    assistance."</TT> <BR>&nbsp;=20
    <P>Proxy: Event based call diversion (recursive)=20
    =
<BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
    Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Announcement</TT>=20
    =
<BR><TT>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Server</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> <BR><TT>|--INV=20
    =
Bob@B------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    |--INV=20
    =
Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
    proxy implements&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
    call forward on 404&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    |--INV AnnServer------------&gt;|</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    |&nbsp; Diversion:=20
    Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> =
<BR><TT>|&lt;-200------------------------------------------|</TT>=20
    <BR><TT>|&lt;=3D=3D=3D"The URL you have dialed B...O...B is =
not=3D=3D|</TT>=20
    <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL =
or=20
    dial&nbsp; |</TT> <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for =

    assistance"</TT> <BR>&nbsp;=20
    <P>Both approaches are viable and there are advantages/disadvantages =
to=20
    each.&nbsp; If all user agents supported local generation of =
announcements,=20
    then an event based call diversion solution may not be needed.&nbsp; =

    However, in today's world, many user agent implementations do not =
have=20
    support for generating local announcements.=20
    <P>Advantages for "event based local announcements" <BR>a) requires =
no=20
    network bandwidth <BR>b) requires no annoucements server=20
    <P>Disadvantages for "event based local announcements" <BR>a) Not =
all SIP=20
    user agents support locally generated announcements <BR>b) =
provisioning=20
    issues for large-scale deployments. (i.e. If desirable, how would a =
network=20
    admin configure multi-vendor SIP phones in his net with certain=20
    announcements).=20
    <P>Advantages for "event based call diversion" <BR>a) Provides =
annoucement=20
    support in multi-vendor networks across all SIP user agents <BR>b)=20
    Provisioning is centralized at proxy and announcement server=20
    <P>Disadvantages for "event based call diversion" <BR>a) requires =
network=20
    bandwidth to play annoucements <BR>b) requires presence of an =
announcements=20
    server=20
    <P>I'm not interested in a holy war of which to use.&nbsp; Each =
solution=20
    will be appropriate for certain network deployments.&nbsp; There =
will soon=20
    be implementations of event based local annoucements and event based =
call=20
    diversion.&nbsp; The more important issue is to define a mechanism =
to get=20
    desired feature interaction. <BR>&nbsp; <BR>&nbsp;=20
    <P>Desired behavior 1: There should be a mechanism so that local=20
    annoucements override network annoucements.=20
    <P>I would like the behavior that locally generated annoucements =
take=20
    precendence over proxy event based call diversion.&nbsp; In other =
words,=20
    given a UA that is configured to play announcement X and proxy that =
is=20
    configured to divert to an announcement server to play message Y, I =
want X=20
    to be played.&nbsp; i.e. I want the behavior of a smart UA to be =
able to=20
    override the behavior (provided by proxies in the network) to dumb =
UAs.=20
    <P>Unfortunately, Po gets a chance to divert the call first: =
<BR>Proxy:=20
    Event based call diversion (recursive)=20
    =
<BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
    Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> <BR><TT>|--INV=20
    =
Bob@B------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    |--INV=20
    =
Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
    proxy implements&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
    call forward on 404&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    |--INV AnnServer------------&gt;|</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    |&nbsp; Diversion:=20
    Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> =
<BR><TT>|&lt;-200------------------------------------------|</TT>=20
    <BR><TT>|&lt;=3D=3D=3D"The URL you have dialed B...O...B is =
not=3D=3D|</TT>=20
    <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL =
or=20
    dial&nbsp; |</TT> <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for =

    assistance"</TT>=20
    <P>Solution 1a: Non-recursive implementation of call diversion <BR>A =

    possible solution would be to implement the diversion =
non-recursively:=20
    <BR>Proxy: Event based call diversion (non-recursive)=20
    =
<BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
    Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> <BR><TT>|--INV=20
    =
Bob@B------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    |--INV=20
    =
Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
    proxy implements&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
    non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
    call forward on 404&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&lt;-302-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> <BR><TT>|&nbsp; Contact:=20
    =
AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> <BR><TT>|&nbsp; Diversion: Bob@B; reason=3D404&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> <BR><TT>|--INV =
AnnServer-------------------------------&gt;|</TT>=20
    <BR><TT>|&nbsp; Diversion: Bob@B; reason=3D404&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> =
<BR><TT>|&lt;-200------------------------------------------|</TT>=20
    <BR><TT>|&lt;=3D=3D=3D"The URL you have dialed B...O...B is =
not=3D=3D|</TT>=20
    <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL =
or=20
    dial&nbsp; |</TT> <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for =

    assistance"</TT>=20
    <P>then the feature interaction could be: <BR>A ignores 302s with =
Diversion=20
    header indicating reason codes for which A local generation of =
annoucements.=20
    <BR>Proxy: Event based call diversion (non-recursive) <BR>User =
agent: Event=20
    based local announcement (overriding 302s with already covered =
Diversion=20
    reason codes)=20
    =
<BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
    Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> <BR><TT>|--INV=20
    =
Bob@B------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    |--INV=20
    =
Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
    proxy implements&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
    non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
    call forward on 404&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&lt;-302-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> <BR><TT>|&nbsp; Contact:=20
    =
AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> <BR><TT>|&nbsp; Diversion: Bob@B; reason=3D404&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> <BR><TT>A generates</TT> <BR><TT>local audio</TT>=20
    <BR><TT>indicating</TT> <BR><TT>"The URL you have dialed B...O...B =
is not in=20
    service, please check the</TT> <BR><TT>&nbsp;URL or dial the =
operator for=20
    assistance."</TT>=20
    <P>Solution 1b: "Supported: annoucements" header <BR>Another =
possible=20
    solution would be for smart UAs (that support announcements) to use =
a=20
    "Supported: annoucements" header.&nbsp; This supported header would =
be used=20
    to indicate to proxies that they should not implement event based =
call=20
    forwarding (for annoucements):=20
    <P>Proxy: Event based call diversion (deferring implementation to =
UAC when=20
    "Supported: annoucements" is present) <BR>User agent: Event based =
local=20
    announcement=20
    =
<BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
    Pt</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    |</TT> <BR><TT>|--INV=20
    =
Bob@B------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
    |</TT> <BR><TT>|&nbsp; Supported:=20
    annoucements&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    |</TT>=20
    =
<BR><TT>|&lt;-404-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    |</TT> <BR><TT>A generates</TT> <BR><TT>local audio</TT>=20
    <BR><TT>indicating</TT> <BR><TT>"The URL you have dialed B...O...B =
is not in=20
    service, please check the</TT> <BR><TT>&nbsp;URL or dial the =
operator for=20
    assistance."</TT> <BR>&nbsp; <BR>&nbsp;=20
    <P>Desired behavior 2:&nbsp; There should be a mechanism so that=20
    announcements are not billable.=20
    <P>Another issue that has been raised w/r/t annoucements in networks =
where=20
    SIP signalling is billable.&nbsp; The concern is that in SIP =
networks where=20
    200 is used to write a start record, implementation of proxy event =
based=20
    call diversion might generate a charge.=20
    <P>Solution 2a: Play annoucements as early media <BR>One solution =
that has=20
    been proposed is to play annoucements as early media:=20
    <P>For example, recursively:=20
    =
<BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
    Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> <BR><TT>|--INV=20
    =
Bob@B------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    |--INV=20
    =
Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
    proxy implements&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
    call forward on 404&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    |--INV AnnServer------------&gt;|</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    |&nbsp; Diversion:=20
    Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> =
<BR><TT>|&lt;-183------------------------------------------|</TT>=20
    <BR><TT>|&nbsp; Content-Disposition:=20
    =
session&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    |</TT> <BR><TT>|&lt;=3D=3D=3D"The URL you have dialed B...O...B is =
not=3D=3D|</TT>=20
    <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL =
or=20
    dial&nbsp; |</TT> <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for =

    assistance"</TT>=20
    <BR><TT>|&lt;-CANCEL---------------------------------------|</TT>=20
    <BR><TT>|--200 (CANCEL)--------------------------------&gt;|</TT>=20
    <P>or non-recursively:=20
    =
<BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
    Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> <BR><TT>|--INV=20
    =
Bob@B------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    |--INV=20
    =
Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
    proxy implements&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
    non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
    call forward on 404&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&lt;-302-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> <BR><TT>|&nbsp; Contact:=20
    =
AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> <BR><TT>|&nbsp; Diversion: Bob@B; reason=3D404&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> <BR><TT>|--INV =
AnnServer-------------------------------&gt;|</TT>=20
    <BR><TT>|&nbsp; Diversion: Bob@B; reason=3D404&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT>=20
    =
<BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
    =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
    |</TT> =
<BR><TT>|&lt;-183------------------------------------------|</TT>=20
    <BR><TT>|&nbsp; Content-Disposition:=20
    =
session&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    |</TT> <BR><TT>|&lt;=3D=3D=3D"The URL you have dialed B...O...B is =
not=3D=3D|</TT>=20
    <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL =
or=20
    dial&nbsp; |</TT> <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for =

    assistance"</TT>=20
    <BR><TT>|&lt;-CANCEL---------------------------------------|</TT>=20
    <BR><TT>|--200 (CANCEL)--------------------------------&gt;|</TT>=20
    <P>Solution 2b: Backend billing system is aware of (non-billable)=20
    Announcement Server URL <BR>Another possible solution is that the =
URL of the=20
    AnnServer could be well-known to the backend billing system and that =
any=20
    accounting records written connection to the AnnServer would not be =
billed.=20
    <P>I'd like to solicit others' ideas, problems, and proposed =
solutions w/r/t=20
    annoucements in SIP.=20
    <P>I'm also looking for co-authors to write an I-D w/r/t=20
    announcements.&nbsp; If interested, please contact me directly at=20
    byerly@cisco.com.=20
    <P>thanks for your help, <BR>Bryan=20
    <P>Bryan J. Byerly <BR>byerly@cisco.com</P></BLOCKQUOTE><BR>&nbsp; =
<BR>&nbsp;=20
  <BR>&nbsp; <BR>&nbsp; </BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_001D_01C0846E.80A8F7C0--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 22 15:39:05 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13872
	for <sip-archive@odin.ietf.org>; Mon, 22 Jan 2001 15:39:04 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9638D4438D; Mon, 22 Jan 2001 14:39:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cybertron.div8.net (HSE-Kitchener-ppp320837.sympatico.ca [64.231.176.84])
	by lists.bell-labs.com (Postfix) with ESMTP id 3D7A54438B
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 14:38:53 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m14KnlW-003EreC@cybertron.div8.net> (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Mon, 22 Jan 2001 15:40:38 -0500 (EST) 
From: Billy Biggs <billy@billybiggs.com>
To: Bryan Byerly <byerly@cisco.com>
Cc: Dinesh Nambisan <dineshn@cisco.com>, SIP List <sip@lists.bell-labs.com>
Subject: Re: [SIP] Announcements in SIP
Message-ID: <20010122154037.B694@div8.net>
References: <FMEKIFKAGKIKCCGGLCNHKEGGCGAA.dineshn@cisco.com> <3A6C922B.1F4A5FA3@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A6C922B.1F4A5FA3@cisco.com>; from byerly@cisco.com on Mon, Jan 22, 2001 at 03:03:55PM -0500
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 22 Jan 2001 15:40:38 -0500

Bryan Byerly (byerly@cisco.com):

> "183" (Session Progress) is the analogous SIP response for Q.931's
> "Progress" message.  Both are end-to-end provisional responses.

  In Q.931 you have a point-to-point connection, while in SIP you have
an unconnected point-to-multipoint tree.  Please read:

    http://lists.bell-labs.com/pipermail/sip/2000q4/004141.html

  for a discussion on the problems with mapping a Q.931 "Progress"
message to early media.  This issue is an ongoing debate.  I strongly
urge for implementors to ensure that all playback of media (including
streaming ringback and announcements) is performed only once a
point-to-point session has been established.

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 22 16:36:55 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15056
	for <sip-archive@odin.ietf.org>; Mon, 22 Jan 2001 16:36:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4461644337; Mon, 22 Jan 2001 15:37:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4])
	by lists.bell-labs.com (Postfix) with SMTP id 0A64044336
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 15:36:25 -0500 (EST)
Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP (
 Tumbleweed MMS SMTP Relay (MMS v4.7)); Mon, 22 Jan 2001 13:35:34 -0800
X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900
Received: by mailserver.sylantro.com with Internet Mail Service (
 5.5.2653.19) id <DNJ73CXX>; Mon, 22 Jan 2001 13:35:33 -0800
Message-ID: <79FEAA5FABA7D411BF580001023D1BBD26D935@mailserver.sylantro.com>
From: "Venkatesh Venkataramanan" <Venkatesh.Venkataramanan@sylantro.com>
To: "Bryan Byerly" <byerly@cisco.com>,
        "Venkatesh Venkataramanan" <Venkatesh.Venkataramanan@sylantro.com>,
        sip@lists.bell-labs.com
Subject: RE: [SIP] Announcements in SIP
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 1672782F22758-01-01
Content-Type: multipart/alternative; 
 boundary="----_=_NextPart_001_01C084BB.3BE9E930"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 22 Jan 2001 13:35:26 -0800

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_01C084BB.3BE9E930
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit

I think usage of the diversion-info here is a nice way to notify the
annc-server. For over-coming the problem with dumb UA's may be we can use
something similar to Alert-Info extension that was proposed to provide
alternate information as regards call progress, infact I propose to rename
Alert-Info to CallProgress-Info so that this header may be used to report
call progress/status of any calls, not just alerting. What do u think of
this ? This header could provide inforamation for playing the particular
annc.
 
So to summarize my thoughts a 404 response shall contain a CallProgress-Info
which provides information to dumb UA's as regards annc. Smart UA's can
ignore this information and provide local annc. Does this sound reasonable?
Any repercussions??
 
Venkatesh
 
-----Original Message-----
From: Bryan Byerly [mailto:byerly@cisco.com]
Sent: Monday, January 22, 2001 11:42 AM
To: Venkatesh Venkataramanan; sip@lists.bell-labs.com
Cc: byerly@cisco.com
Subject: Re: [SIP] Announcements in SIP



Venkatesh Venkataramanan wrote: 

 Alternate Suggestion:If I understand 404 response right, all that the
proxies do today is to forward them down to the UA. So, instead of making
the proxy either translate the 404 to a 302 or implementing call forwarding
to an annc server on receipt of a 404, I was thinking more on the lines of
just forwarding the 404 response down to the UA, very much like today,
except that the proxy adds a Contact: AnncServer_URL. A smart UA (that can
provide local annc would do so, seeing the 404) where as a UA that doesn't
have any local playback capabilities would contact the Contact: URL to
provide local announcements. So, no extensions involved (except the work of
adding a Contact in a 404 response). Any thoughts on this suggestion?


The approach using a Contact in the response would also work for smart UAs. 


A              Po             Pt           AnnServer 
|              |              |                | 
|--INV Bob@Po->|              |                | 
|              |--INV Bob@Pt->|                |
|              |              |                | 
|              |<-404---------|                | 
|              |              |                | 
|<-404---------|              |                | 
|  Contact: AnnServer         |                | 
|              |              |                | 
|--INV AnnServer------------------------------>| 
|              |              |                | 
|<-183/200-------------------------------------| 
|              |              |                | 
|<="The URL you have dialed B...O...B at Pt is=| 
|   unrouteable, please check the URL or       | 
|   contact your system admin for assistance"  | 
  
  


However, 
a) this doesn't provide an announcements solution for dumb UAs 
b) I doubt a smart UA would even need an AnnServer contact.  Since he's
smart, he would either 1) be able to generate annoucements locally or 2)
know the FQDN/IP address of the AnnServer directly.  I'm not aware that
smart UAs need any proxy assist. (Although, they would need to be able to
turn off proxy assist). 


In the proposal above, how would the Announcement server know to say
"B...O...B"? 
One solution would be for the Annoucement server to examine the Diversion
header (draft-levy-sip-diversion-01.txt).  The Diversion header provides the
necessary supplemental information to the announcement server.  Since the
Diversion header is already needed for voicemail servers, I think it is a
good candidate for usage here. 


What do you think? 


thanks, 
Bryan 


Bryan J. Byerly 
byerly@cisco.com 
  


-----Original Message----- 
From: Bryan Byerly [ mailto:byerly@cisco.com <mailto:byerly@cisco.com> ] 
Sent: Monday, January 22, 2001 8:54 AM 
To: sip@lists.bell-labs.com 
Cc: byerly@cisco.com 
Subject: [SIP] Announcements in SIP 
 
Hi guys, 

I'd like to solicit ideas/consensus w/r/t announcements in SIP. 


For this thread of discussion, we're talking about announcements which are
played when an error occurred during call setup.  For instance, on 404, a
message could be played "The URL you have dialed B...O...B. is not in
service, please check the URL or dial the operator for assistance". 


There are at least two desired behaviors w/r/t annoucements: 
Desired behavior 1: There should be a mechanism so that local annoucements
override network annoucements. 
Desired behavior 2: There should be a mechanism so that announcements are
not billable. 


Like call forwarding features in SIP, there are implementable solutions to
play annoucements using user agents or proxies. 


In the diagrams below, A, B, and C are user agents, Po is an originating
proxy and Pt is a terminating proxy. 


User agent: Event based local announcement 
A                 Po             Pt 
|                  |              | 
|--INV Bob@B------>|              | 
|                  |              | 
|<-404-------------|              | 
|                  |              | 
A generates 
local audio 
indicating 
"The URL you have dialed B...O...B is not in service, please check the 
 URL or dial the operator for assistance." 
  


Proxy: Event based call diversion (recursive) 
A                  Po             Pt        Announcement 
                                              Server 
|                  |              |             | 
|--INV Bob@B------>|              |             | 
|                  |--INV Bob@B-->|             | 
|                  |<-404---------|             | 
|            proxy implements     |             | 
|            call forward on 404  |             | 
|                  |--INV AnnServer------------>| 
|                  |  Diversion: Bob@B          | 
|                  |              |             | 
|<-200------------------------------------------| 
|<==="The URL you have dialed B...O...B is not==| 
|     in service, please check the URL or dial  | 
|     the operator for assistance" 
  


Both approaches are viable and there are advantages/disadvantages to each.
If all user agents supported local generation of announcements, then an
event based call diversion solution may not be needed.  However, in today's
world, many user agent implementations do not have support for generating
local announcements. 


Advantages for "event based local announcements" 
a) requires no network bandwidth 
b) requires no annoucements server 


Disadvantages for "event based local announcements" 
a) Not all SIP user agents support locally generated announcements 
b) provisioning issues for large-scale deployments. (i.e. If desirable, how
would a network admin configure multi-vendor SIP phones in his net with
certain announcements). 


Advantages for "event based call diversion" 
a) Provides annoucement support in multi-vendor networks across all SIP user
agents 
b) Provisioning is centralized at proxy and announcement server 


Disadvantages for "event based call diversion" 
a) requires network bandwidth to play annoucements 
b) requires presence of an announcements server 


I'm not interested in a holy war of which to use.  Each solution will be
appropriate for certain network deployments.  There will soon be
implementations of event based local annoucements and event based call
diversion.  The more important issue is to define a mechanism to get desired
feature interaction. 
  
  


Desired behavior 1: There should be a mechanism so that local annoucements
override network annoucements. 


I would like the behavior that locally generated annoucements take
precendence over proxy event based call diversion.  In other words, given a
UA that is configured to play announcement X and proxy that is configured to
divert to an announcement server to play message Y, I want X to be played.
i.e. I want the behavior of a smart UA to be able to override the behavior
(provided by proxies in the network) to dumb UAs. 


Unfortunately, Po gets a chance to divert the call first: 
Proxy: Event based call diversion (recursive) 
A                  Po             Pt         AnnServer 
|                  |              |             | 
|--INV Bob@B------>|              |             | 
|                  |--INV Bob@B-->|             | 
|                  |<-404---------|             | 
|            proxy implements     |             | 
|            call forward on 404  |             | 
|                  |--INV AnnServer------------>| 
|                  |  Diversion: Bob@B          | 
|                  |              |             | 
|<-200------------------------------------------| 
|<==="The URL you have dialed B...O...B is not==| 
|     in service, please check the URL or dial  | 
|     the operator for assistance" 


Solution 1a: Non-recursive implementation of call diversion 
A possible solution would be to implement the diversion non-recursively: 
Proxy: Event based call diversion (non-recursive) 
A                  Po             Pt         AnnServer 
|                  |              |             | 
|--INV Bob@B------>|              |             | 
|                  |--INV Bob@B-->|             | 
|                  |<-404---------|             | 
|            proxy implements     |             | 
|            non-recursive        |             | 
|            call forward on 404  |             | 
|<-302-------------|              |             | 
|  Contact: AnnServer             |             | 
|  Diversion: Bob@B; reason=404   |             | 
|                  |              |             | 
|--INV AnnServer------------------------------->| 
|  Diversion: Bob@B; reason=404   |             | 
|                  |              |             | 
|<-200------------------------------------------| 
|<==="The URL you have dialed B...O...B is not==| 
|     in service, please check the URL or dial  | 
|     the operator for assistance" 


then the feature interaction could be: 
A ignores 302s with Diversion header indicating reason codes for which A
local generation of annoucements. 
Proxy: Event based call diversion (non-recursive) 
User agent: Event based local announcement (overriding 302s with already
covered Diversion reason codes) 
A                  Po             Pt         AnnServer 
|                  |              |             | 
|--INV Bob@B------>|              |             | 
|                  |--INV Bob@B-->|             | 
|                  |<-404---------|             | 
|            proxy implements     |             | 
|            non-recursive        |             | 
|            call forward on 404  |             | 
|<-302-------------|              |             | 
|  Contact: AnnServer             |             | 
|  Diversion: Bob@B; reason=404   |             | 
|                  |              |             | 
A generates 
local audio 
indicating 
"The URL you have dialed B...O...B is not in service, please check the 
 URL or dial the operator for assistance." 


Solution 1b: "Supported: annoucements" header 
Another possible solution would be for smart UAs (that support
announcements) to use a "Supported: annoucements" header.  This supported
header would be used to indicate to proxies that they should not implement
event based call forwarding (for annoucements): 


Proxy: Event based call diversion (deferring implementation to UAC when
"Supported: annoucements" is present) 
User agent: Event based local announcement 
A                 Po             Pt 
|                  |              | 
|--INV Bob@B------>|              | 
|  Supported: annoucements        | 
|                  |              | 
|<-404-------------|              | 
|                  |              | 
A generates 
local audio 
indicating 
"The URL you have dialed B...O...B is not in service, please check the 
 URL or dial the operator for assistance." 
  
  


Desired behavior 2:  There should be a mechanism so that announcements are
not billable. 


Another issue that has been raised w/r/t annoucements in networks where SIP
signalling is billable.  The concern is that in SIP networks where 200 is
used to write a start record, implementation of proxy event based call
diversion might generate a charge. 


Solution 2a: Play annoucements as early media 
One solution that has been proposed is to play annoucements as early media: 


For example, recursively: 
A                  Po             Pt         AnnServer 
|                  |              |             | 
|--INV Bob@B------>|              |             | 
|                  |--INV Bob@B-->|             | 
|                  |<-404---------|             | 
|            proxy implements     |             | 
|            call forward on 404  |             | 
|                  |--INV AnnServer------------>| 
|                  |  Diversion: Bob@B          | 
|                  |              |             | 
|<-183------------------------------------------| 
|  Content-Disposition: session                 | 
|<==="The URL you have dialed B...O...B is not==| 
|     in service, please check the URL or dial  | 
|     the operator for assistance" 
|<-CANCEL---------------------------------------| 
|--200 (CANCEL)-------------------------------->| 


or non-recursively: 
A                  Po             Pt         AnnServer 
|                  |              |             | 
|--INV Bob@B------>|              |             | 
|                  |--INV Bob@B-->|             | 
|                  |<-404---------|             | 
|            proxy implements     |             | 
|            non-recursive        |             | 
|            call forward on 404  |             | 
|<-302-------------|              |             | 
|  Contact: AnnServer             |             | 
|  Diversion: Bob@B; reason=404   |             | 
|                  |              |             | 
|--INV AnnServer------------------------------->| 
|  Diversion: Bob@B; reason=404   |             | 
|                  |              |             | 
|<-183------------------------------------------| 
|  Content-Disposition: session                 | 
|<==="The URL you have dialed B...O...B is not==| 
|     in service, please check the URL or dial  | 
|     the operator for assistance" 
|<-CANCEL---------------------------------------| 
|--200 (CANCEL)-------------------------------->| 


Solution 2b: Backend billing system is aware of (non-billable) Announcement
Server URL 
Another possible solution is that the URL of the AnnServer could be
well-known to the backend billing system and that any accounting records
written connection to the AnnServer would not be billed. 


I'd like to solicit others' ideas, problems, and proposed solutions w/r/t
annoucements in SIP. 


I'm also looking for co-authors to write an I-D w/r/t announcements.  If
interested, please contact me directly at byerly@cisco.com. 


thanks for your help, 
Bryan 


Bryan J. Byerly 
byerly@cisco.com 
  
 


  


------_=_NextPart_001_01C084BB.3BE9E930
Content-Type: text/html; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=421564519-22012001>I 
think usage of the diversion-info here is a&nbsp;nice way to notify the 
annc-server. For over-coming the problem with dumb UA's may be we can use 
something similar to Alert-Info extension that was proposed to provide alternate 
information as regards call progress, infact I propose to rename Alert-Info to 
CallProgress-Info so that this header may be used to report call progress/status 
of any calls, not just alerting. What do u think of this ? This header could 
provide inforamation for&nbsp;playing the particular annc.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=421564519-22012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=421564519-22012001>So to 
summarize my thoughts a 404 response shall contain a CallProgress-Info which 
provides information to dumb UA's as regards annc. Smart UA's can ignore this 
information and provide local annc. Does this sound reasonable? Any 
repercussions??</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=421564519-22012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=421564519-22012001>Venkatesh</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=421564519-22012001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=421564519-22012001></SPAN></FONT><FONT face=Tahoma size=2>-----Original 
Message-----<BR><B>From:</B> Bryan Byerly 
[mailto:byerly@cisco.com]<BR><B>Sent:</B> Monday, January 22, 2001 11:42 
AM<BR><B>To:</B> Venkatesh Venkataramanan; sip@lists.bell-labs.com<BR><B>Cc:</B> 
byerly@cisco.com<BR><B>Subject:</B> Re: [SIP] Announcements in SIP<BR><BR></DIV>
<BLOCKQUOTE></FONT>Venkatesh Venkataramanan wrote: 
  <BLOCKQUOTE TYPE="CITE">&nbsp;<SPAN class=593565817-22012001><FONT 
    face=Arial><FONT color=#0000ff><FONT size=-1>Alternate 
    Suggestion:</FONT></FONT></FONT></SPAN><SPAN class=593565817-22012001><FONT 
    face=Arial><FONT color=#0000ff><FONT size=-1>If I understand 404 response 
    right, all that the proxies do today is to forward them down to the UA. So, 
    instead of making the proxy either translate the 404 to a 302 or 
    implementing call forwarding to an annc server on receipt of a 404, I was 
    thinking more on the lines of just forwarding the 404 response down to the 
    UA, very much like today, except that the proxy adds a Contact: 
    AnncServer_URL. A smart UA (that can provide local annc would do so, seeing 
    the 404) where as a UA that doesn't have any local playback capabilities 
    would contact the Contact: URL to provide local announcements. So, no 
    extensions involved (except the work of adding a Contact in a 404 
    response).</FONT></FONT></FONT></SPAN>&nbsp;<SPAN 
    class=593565817-22012001><FONT face=Arial><FONT color=#0000ff><FONT 
    size=-1>Any thoughts on this 
  suggestion?</FONT></FONT></FONT></SPAN></BLOCKQUOTE>
  <P><BR>The approach using a Contact in the response would also work for smart 
  UAs. 
  <P><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</TT> 
  <BR><TT>|&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;&nbsp; 
  |</TT> <BR><TT>|--INV 
  Bob@Po-&gt;|&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; 
  |</TT> 
  <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  |--INV 
  Bob@Pt-&gt;|&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;&nbsp; 
  |</TT> 
  <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  |&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  |</TT> 
  <BR><TT>|&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;&nbsp; 
  |</TT> 
  <BR><TT>|&lt;-404---------|&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; 
  |</TT> <BR><TT>| 
  &nbsp;Contact:&nbsp;AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  |</TT> 
  <BR><TT>|&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;&nbsp; 
  |</TT> <BR><TT>|--INV AnnServer------------------------------&gt;|</TT> 
  <BR><TT>|&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;&nbsp; 
  |</TT> <BR><TT>|&lt;-183/200-------------------------------------|</TT> 
  <BR><TT>|&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;&nbsp; 
  |</TT> <BR><TT>|&lt;="The URL&nbsp;you have dialed B...O...B at Pt is=|</TT> 
  <BR><TT>|&nbsp;&nbsp; unrouteable, please check the 
  URL&nbsp;or&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> <BR><TT>|&nbsp;&nbsp; 
  contact your system admin for assistance"&nbsp; |</TT> <BR>&nbsp; <BR>&nbsp; 
  <P>However, <BR>a)&nbsp;this doesn't provide an announcements solution for 
  dumb UAs <BR>b)&nbsp;I doubt a smart UA&nbsp;would even need an AnnServer 
  contact.&nbsp; Since he's smart, he would either 1)&nbsp;be able to generate 
  annoucements locally or 2)&nbsp;know the FQDN/IP&nbsp;address of the AnnServer 
  directly.&nbsp; I'm not aware that smart UAs need any proxy assist. (Although, 
  they would need to be able to turn off proxy assist). 
  <P>In the proposal above, how would the Announcement server know to say 
  "B...O...B"? <BR>One solution would be for the Annoucement server to examine 
  the Diversion header (draft-levy-sip-diversion-01.txt).&nbsp; The Diversion 
  header provides the necessary supplemental information to the announcement 
  server.&nbsp; Since the Diversion header is already needed for voicemail 
  servers, I&nbsp;think it is a good candidate for usage here. 
  <P>What do you think? 
  <P>thanks, <BR>Bryan 
  <P>Bryan J. Byerly <BR>byerly@cisco.com <BR>&nbsp; 
  <BLOCKQUOTE TYPE="CITE">
    <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
      <DIV class=OutlookMessageHeader dir=ltr><FONT face=Tahoma><FONT 
      size=-1>-----Original Message-----</FONT></FONT> <BR><FONT 
      face=Tahoma><FONT size=-1><B>From:</B> Bryan Byerly [<A 
      href="mailto:byerly@cisco.com">mailto:byerly@cisco.com</A>]</FONT></FONT> 
      <BR><FONT face=Tahoma><FONT size=-1><B>Sent:</B> Monday, January 22, 2001 
      8:54 AM</FONT></FONT> <BR><FONT face=Tahoma><FONT size=-1><B>To:</B> 
      sip@lists.bell-labs.com</FONT></FONT> <BR><FONT face=Tahoma><FONT 
      size=-1><B>Cc:</B> byerly@cisco.com</FONT></FONT> <BR><FONT 
      face=Tahoma><FONT size=-1><B>Subject:</B> [SIP] Announcements in 
      SIP</FONT></FONT> <BR>&nbsp;</DIV>Hi guys, 
      <P>I'd like to solicit ideas/consensus w/r/t announcements in SIP. 
      <P>For this thread of discussion, we're talking about announcements which 
      are played when an error occurred during call setup.&nbsp; For instance, 
      on 404, a message could be played "The URL you have dialed B...O...B. is 
      not in service, please check the URL or dial the operator for assistance". 

      <P>There are at least two desired behaviors w/r/t annoucements: 
      <BR>Desired behavior 1: There should be a mechanism so that local 
      annoucements override network annoucements. <BR>Desired behavior 2: There 
      should be a mechanism so that announcements are not billable. 
      <P>Like call forwarding features in SIP, there are implementable solutions 
      to play annoucements using user agents or proxies. 
      <P>In the diagrams below, A, B, and C are user agents, Po is an 
      originating proxy and Pt is a terminating proxy. 
      <P>User agent: Event based local announcement 
      <BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Pt</TT> 
      <BR><TT>|&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; 
      |</TT> <BR><TT>|--INV 
      Bob@B------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&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; 
      |</TT> 
      <BR><TT>|&lt;-404-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&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; 
      |</TT> <BR><TT>A generates</TT> <BR><TT>local audio</TT> 
      <BR><TT>indicating</TT> <BR><TT>"The URL you have dialed B...O...B is not 
      in service, please check the</TT> <BR><TT>&nbsp;URL or dial the operator 
      for assistance."</TT> <BR>&nbsp; 
      <P>Proxy: Event based call diversion (recursive) 
      <BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Announcement</TT> 
      <BR><TT>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Server</TT> 
      <BR><TT>|&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;&nbsp;&nbsp; 
      |</TT> <BR><TT>|--INV 
      Bob@B------&gt;|&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; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |--INV 
      Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      proxy implements&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      call forward on 404&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |--INV AnnServer------------&gt;|</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp; Diversion: 
      Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>|&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;&nbsp;&nbsp; 
      |</TT> <BR><TT>|&lt;-200------------------------------------------|</TT> 
      <BR><TT>|&lt;==="The URL you have dialed B...O...B is not==|</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or 
      dial&nbsp; |</TT> <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for 
      assistance"</TT> <BR>&nbsp; 
      <P>Both approaches are viable and there are advantages/disadvantages to 
      each.&nbsp; If all user agents supported local generation of 
      announcements, then an event based call diversion solution may not be 
      needed.&nbsp; However, in today's world, many user agent implementations 
      do not have support for generating local announcements. 
      <P>Advantages for "event based local announcements" <BR>a) requires no 
      network bandwidth <BR>b) requires no annoucements server 
      <P>Disadvantages for "event based local announcements" <BR>a) Not all SIP 
      user agents support locally generated announcements <BR>b) provisioning 
      issues for large-scale deployments. (i.e. If desirable, how would a 
      network admin configure multi-vendor SIP phones in his net with certain 
      announcements). 
      <P>Advantages for "event based call diversion" <BR>a) Provides annoucement 
      support in multi-vendor networks across all SIP user agents <BR>b) 
      Provisioning is centralized at proxy and announcement server 
      <P>Disadvantages for "event based call diversion" <BR>a) requires network 
      bandwidth to play annoucements <BR>b) requires presence of an 
      announcements server 
      <P>I'm not interested in a holy war of which to use.&nbsp; Each solution 
      will be appropriate for certain network deployments.&nbsp; There will soon 
      be implementations of event based local annoucements and event based call 
      diversion.&nbsp; The more important issue is to define a mechanism to get 
      desired feature interaction. <BR>&nbsp; <BR>&nbsp; 
      <P>Desired behavior 1: There should be a mechanism so that local 
      annoucements override network annoucements. 
      <P>I would like the behavior that locally generated annoucements take 
      precendence over proxy event based call diversion.&nbsp; In other words, 
      given a UA that is configured to play announcement X and proxy that is 
      configured to divert to an announcement server to play message Y, I want X 
      to be played.&nbsp; i.e. I want the behavior of a smart UA to be able to 
      override the behavior (provided by proxies in the network) to dumb UAs. 
      <P>Unfortunately, Po gets a chance to divert the call first: <BR>Proxy: 
      Event based call diversion (recursive) 
      <BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</TT> 
      <BR><TT>|&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;&nbsp;&nbsp; 
      |</TT> <BR><TT>|--INV 
      Bob@B------&gt;|&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; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |--INV 
      Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      proxy implements&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      call forward on 404&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |--INV AnnServer------------&gt;|</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp; Diversion: 
      Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>|&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;&nbsp;&nbsp; 
      |</TT> <BR><TT>|&lt;-200------------------------------------------|</TT> 
      <BR><TT>|&lt;==="The URL you have dialed B...O...B is not==|</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or 
      dial&nbsp; |</TT> <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for 
      assistance"</TT> 
      <P>Solution 1a: Non-recursive implementation of call diversion <BR>A 
      possible solution would be to implement the diversion non-recursively: 
      <BR>Proxy: Event based call diversion (non-recursive) 
      <BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</TT> 
      <BR><TT>|&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;&nbsp;&nbsp; 
      |</TT> <BR><TT>|--INV 
      Bob@B------&gt;|&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; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |--INV 
      Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      proxy implements&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      call forward on 404&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&lt;-302-------------|&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; 
      |</TT> <BR><TT>|&nbsp; Contact: 
      AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> <BR><TT>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&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;&nbsp;&nbsp; 
      |</TT> <BR><TT>|--INV AnnServer-------------------------------&gt;|</TT> 
      <BR><TT>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&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;&nbsp;&nbsp; 
      |</TT> <BR><TT>|&lt;-200------------------------------------------|</TT> 
      <BR><TT>|&lt;==="The URL you have dialed B...O...B is not==|</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or 
      dial&nbsp; |</TT> <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for 
      assistance"</TT> 
      <P>then the feature interaction could be: <BR>A ignores 302s with 
      Diversion header indicating reason codes for which A local generation of 
      annoucements. <BR>Proxy: Event based call diversion (non-recursive) 
      <BR>User agent: Event based local announcement (overriding 302s with 
      already covered Diversion reason codes) 
      <BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</TT> 
      <BR><TT>|&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;&nbsp;&nbsp; 
      |</TT> <BR><TT>|--INV 
      Bob@B------&gt;|&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; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |--INV 
      Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      proxy implements&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      call forward on 404&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&lt;-302-------------|&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; 
      |</TT> <BR><TT>|&nbsp; Contact: 
      AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> <BR><TT>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&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;&nbsp;&nbsp; 
      |</TT> <BR><TT>A generates</TT> <BR><TT>local audio</TT> 
      <BR><TT>indicating</TT> <BR><TT>"The URL you have dialed B...O...B is not 
      in service, please check the</TT> <BR><TT>&nbsp;URL or dial the operator 
      for assistance."</TT> 
      <P>Solution 1b: "Supported: annoucements" header <BR>Another possible 
      solution would be for smart UAs (that support announcements) to use a 
      "Supported: annoucements" header.&nbsp; This supported header would be 
      used to indicate to proxies that they should not implement event based 
      call forwarding (for annoucements): 
      <P>Proxy: Event based call diversion (deferring implementation to UAC when 
      "Supported: annoucements" is present) <BR>User agent: Event based local 
      announcement 
      <BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Pt</TT> 
      <BR><TT>|&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; 
      |</TT> <BR><TT>|--INV 
      Bob@B------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> <BR><TT>|&nbsp; Supported: 
      annoucements&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>|&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; 
      |</TT> 
      <BR><TT>|&lt;-404-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&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; 
      |</TT> <BR><TT>A generates</TT> <BR><TT>local audio</TT> 
      <BR><TT>indicating</TT> <BR><TT>"The URL you have dialed B...O...B is not 
      in service, please check the</TT> <BR><TT>&nbsp;URL or dial the operator 
      for assistance."</TT> <BR>&nbsp; <BR>&nbsp; 
      <P>Desired behavior 2:&nbsp; There should be a mechanism so that 
      announcements are not billable. 
      <P>Another issue that has been raised w/r/t annoucements in networks where 
      SIP signalling is billable.&nbsp; The concern is that in SIP networks 
      where 200 is used to write a start record, implementation of proxy event 
      based call diversion might generate a charge. 
      <P>Solution 2a: Play annoucements as early media <BR>One solution that has 
      been proposed is to play annoucements as early media: 
      <P>For example, recursively: 
      <BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</TT> 
      <BR><TT>|&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;&nbsp;&nbsp; 
      |</TT> <BR><TT>|--INV 
      Bob@B------&gt;|&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; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |--INV 
      Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      proxy implements&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      call forward on 404&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |--INV AnnServer------------&gt;|</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp; Diversion: 
      Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
      <BR><TT>|&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;&nbsp;&nbsp; 
      |</TT> <BR><TT>|&lt;-183------------------------------------------|</TT> 
      <BR><TT>|&nbsp; Content-Disposition: 
      session&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> <BR><TT>|&lt;==="The URL you have dialed B...O...B is not==|</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or 
      dial&nbsp; |</TT> <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for 
      assistance"</TT> 
      <BR><TT>|&lt;-CANCEL---------------------------------------|</TT> 
      <BR><TT>|--200 (CANCEL)--------------------------------&gt;|</TT> 
      <P>or non-recursively: 
      <BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</TT> 
      <BR><TT>|&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;&nbsp;&nbsp; 
      |</TT> <BR><TT>|--INV 
      Bob@B------&gt;|&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; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |--INV 
      Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      proxy implements&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      call forward on 404&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&lt;-302-------------|&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; 
      |</TT> <BR><TT>|&nbsp; Contact: 
      AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> <BR><TT>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&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;&nbsp;&nbsp; 
      |</TT> <BR><TT>|--INV AnnServer-------------------------------&gt;|</TT> 
      <BR><TT>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&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;&nbsp;&nbsp; 
      |</TT> <BR><TT>|&lt;-183------------------------------------------|</TT> 
      <BR><TT>|&nbsp; Content-Disposition: 
      session&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> <BR><TT>|&lt;==="The URL you have dialed B...O...B is not==|</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or 
      dial&nbsp; |</TT> <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for 
      assistance"</TT> 
      <BR><TT>|&lt;-CANCEL---------------------------------------|</TT> 
      <BR><TT>|--200 (CANCEL)--------------------------------&gt;|</TT> 
      <P>Solution 2b: Backend billing system is aware of (non-billable) 
      Announcement Server URL <BR>Another possible solution is that the URL of 
      the AnnServer could be well-known to the backend billing system and that 
      any accounting records written connection to the AnnServer would not be 
      billed. 
      <P>I'd like to solicit others' ideas, problems, and proposed solutions 
      w/r/t annoucements in SIP. 
      <P>I'm also looking for co-authors to write an I-D w/r/t 
      announcements.&nbsp; If interested, please contact me directly at 
      byerly@cisco.com. 
      <P>thanks for your help, <BR>Bryan 
      <P>Bryan J. Byerly <BR>byerly@cisco.com <BR>&nbsp; 
    <BR>&nbsp;</P></BLOCKQUOTE></BLOCKQUOTE><BR>&nbsp; </BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C084BB.3BE9E930--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 22 17:10:56 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15607
	for <sip-archive@odin.ietf.org>; Mon, 22 Jan 2001 17:10:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A318744345; Mon, 22 Jan 2001 16:11:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from host.ott.igs.net (host.ott.igs.net [216.58.1.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 1AAA244336
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 16:10:38 -0500 (EST)
Received: from [216.58.19.19] (ttyL09.ott.igs.net [216.58.7.89])
	by host.ott.igs.net (8.9.3/8.9.2) with ESMTP id RAA64251
	for <sip@lists.research.bell-labs.com>; Mon, 22 Jan 2001 17:10:24 -0500 (EST)
	(envelope-from kgk@igs.net)
Mime-Version: 1.0
X-Sender: kgk@host.igs.net
Message-Id: <v04210108b6921ad147bf@[216.58.19.19]>
To: sip@lists.bell-labs.com
From: Keith Knightson <kgk@igs.net>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: [SIP] sip penetration
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 22 Jan 2001 12:19:26 -0500

Dear Sip'ers,

I know one is not supposed to discuss such things on these lists but, 
I would like to get a feel for the future of sip vs h.323.

Does anyone have any info on the current usage penetration of sip vs 
h323, or know of any predictive forecasts for same.

Some/any pointers would be appreciated.

Regards

Keith

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 22 20:52:56 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18942
	for <sip-archive@odin.ietf.org>; Mon, 22 Jan 2001 20:52:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7B90344344; Mon, 22 Jan 2001 19:53:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cwcsun41.cwc.nus.edu.sg (cwcsun41.cwc.nus.edu.sg [137.132.163.102])
	by lists.bell-labs.com (Postfix) with ESMTP id 4197D44336
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 19:52:06 -0500 (EST)
Received: from spiderman.cwc.nus.edu.sg ([172.16.3.239])
	by cwcsun41.cwc.nus.edu.sg (8.9.3/8.9.3) with ESMTP id JAA17691
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 09:50:47 +0800 (SGT)
Message-Id: <4.3.2.7.2.20010123094811.00a9eca0@postman.cwc.nus.edu.sg>
X-Sender: tansk@postman.cwc.nus.edu.sg
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: sip@lists.bell-labs.com
From: Tan Seng Kee <tansk@cwc.nus.edu.sg>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] Is G.723.1 codec of Quicknet card used ?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 23 Jan 2001 09:54:18 +0800

HI,

I would like to seek help inasking whether the Quicknet Card's G.723.1 
codec is being utilized in the SIP ?

I had tried to trace the source code but I can not find the exist place 
where it set the SDP media description to G.723.1 for RTP.  If it does 
being set some where, please kindly specify the file and methods that set 
the RTP payload to G.723.1.

Thank you.

Seng Kee, Tan


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 23 01:03:58 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23098
	for <sip-archive@odin.ietf.org>; Tue, 23 Jan 2001 01:03:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 87B6F44359; Tue, 23 Jan 2001 00:04:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id C7FBB44336
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 00:03:16 -0500 (EST)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id WAA04505
	for <sip@lists.bell-labs.com>; Mon, 22 Jan 2001 22:03:14 -0800 (PST)
Received: from sony-laptop (ssh-sj1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint)
	with SMTP id AAI07213;
	Mon, 22 Jan 2001 22:03:00 -0800 (PST)
Message-Id: <4.1.20010122214224.00b63850@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
To: sip@lists.bell-labs.com
From: Rohan Mahy <rohan@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [SIP] Agenda/location for Interim meeting
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 22 Jan 2001 22:09:26 -0800

Hi Folks,

Below is a rough agenda for the interim meeting on Feb 8th and 9th. I've
asked the relevant folks shown to moderate discussions in each area.  If
you have a draft or idea you have presented on the list and want to present
topics/issues, please contact them.  Dean, can you please create a web page
for the agenda and any relevant drafts/presos?

Presentations should NOT be tutorial in nature and should list the
issues/choices/differences at hand.  Presentations must conform to the
usual IETF rules (no logos, etc.).

Thursday Feb 8th
08:00  Logisitics and Agenda Bashing					Dean Willis
08:30  SUBSCRIBE/NOTIFY (split with presence docs, forking)		Adam Roach
11:00  Call Control Models (3pcc vs. phonectl vs. peer-to-peer 3pcc)	Rohan
12:30  Break for Lunch (provided)
13:30  REFER issues							Robert Sparks
16:30  SIP device configuration						Rick Dean
17:30  Dinner
19:00  SIP conferencing						Henning
21:00  Stop for the night

Friday Feb 9th
08:00  Base spec open issues: (Record Routing, Early Media, ...)	Jonathan R
12:00  Break for Lunch (provided)
13:00  Firewall/NAT traversal						Jonathan R
15:00  AAA requirements						Jon Peterson
17:00  Close

Robert Sparks of Dynamicsoft has volunteered the use of a meeting room at
their offices:
	5100 Tennyson Parkway
	Suite 1200
	Plano, Texas 75024
This is a smallish room, so if you show up but didn't tell me that you are
coming, there probably won't be any chairs/space left.

Cisco/Rohan will provide a simple lunch (probably sandwiches). 

Directions are available at:
	http://www.dynamicsoft.com/contact/dynamicsoft_locations.html#Texas Office 

There are many, many hotels within a 5 miles radius.  Several folks appear
to be staying at the Residence Inn mentioned on the web page above.

Only 4 people have contacted me asking to call in for the meeting.  Unless
I hear from more of you in the next few days, I will reserve 6 ports on a
conference bridge.

thanks,
-rohan


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 23 04:23:57 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07856
	for <sip-archive@odin.ietf.org>; Tue, 23 Jan 2001 04:23:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 04F8444349; Tue, 23 Jan 2001 03:24:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from dogbert.isdn-comms.co.uk (unknown [212.56.122.225])
	by lists.bell-labs.com (Postfix) with ESMTP id D7AEB44336
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 03:23:49 -0500 (EST)
Received: from isdn-comms.co.uk (dilbert.isdn-comms.co.uk [169.254.4.1])
	by dogbert.isdn-comms.co.uk (8.9.3/8.9.3) with ESMTP id JAA06504;
	Tue, 23 Jan 2001 09:21:45 GMT
Received: from isdn-comms.co.uk [169.254.128.4] by isdn-comms.co.uk (FTGate 2, 2, 0, 1);
     Tue, 23 Jan 01 09:23:20 +0000
Message-ID: <3A6D4F3F.84586A02@isdn-comms.co.uk>
From: Chris Wayman Purvis <cwp@isdn-comms.co.uk>
Organization: ISDN Communications Ltd
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Dan Sahar <dans@kagoor.com>
Cc: "'SIP discussion list'" <SIP@lists.bell-labs.com>
Subject: Re: [SIP] SIP Media Session
References: <DMEFILDNOHJNADOFDHCCCEGMCCAA.dans@kagoor.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 23 Jan 2001 09:30:39 +0000
Content-Transfer-Encoding: 7bit

Dan,

Yes and yes.

Chris

> Dan Sahar wrote:
> 
> I've been using an H323 call generator comprised of a signalling and RTP/RTCP
> generation modules.
> 
> Is it possible to combine the RTP generator with a SIP signalling
> generator into a SIP call generator?
> 
> In other words, is the RTP media layer identical no matter what the
> session initiation protocol is?
> 
> Thanx in advance.
> 
> Regards,
> 
> Dan Sahar
> Kagoor Networks Ltd.
> E-mail: mailto:dans@kagoor.com
> Web: www.kagoor.com
> ______________________________
> "..he not busy being born is busy dying."
> ~Bob Dylan
> 
> 

-- 
Dr Chris Purvis -- Development Manager
ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
Phone: +44 1344 899 007
Fax:   +44 1344 899 001

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 23 08:30:57 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10906
	for <sip-archive@odin.ietf.org>; Tue, 23 Jan 2001 08:30:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B168F44346; Tue, 23 Jan 2001 07:31:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.bell-labs.com (Postfix) with ESMTP id 2E37544336
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 06:34:50 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09484;
	Tue, 23 Jan 2001 07:34:38 -0500 (EST)
Message-Id: <200101231234.HAA09484@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@lists.bell-labs.com
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: [SIP] I-D ACTION:draft-ietf-sip-dhcp-03.txt
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 23 Jan 2001 07:34:38 -0500

--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		: DHCP Option for SIP Servers
	Author(s)	: G. Nair, H. Schulzrinne
	Filename	: draft-ietf-sip-dhcp-03.txt
	Pages		: 4
	Date		: 22-Jan-01
	
This document defines a DHCP option that contains a single name that
can be mapped to one or more SIP outbound proxy servers. This is one
of the many methods that a SIP client can use to obtain the addresses
of such a local SIP server.

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

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-dhcp-03.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-dhcp-03.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:	<20010122143536.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-dhcp-03.txt

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

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

--OtherAccess--

--NextPart--



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 23 08:32:16 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10951
	for <sip-archive@odin.ietf.org>; Tue, 23 Jan 2001 08:32:16 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F16434436F; Tue, 23 Jan 2001 07:31:15 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by lists.bell-labs.com (Postfix) with ESMTP id 4BCF344336
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 06:34:55 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09500;
	Tue, 23 Jan 2001 07:34:43 -0500 (EST)
Message-Id: <200101231234.HAA09500@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: sip@lists.bell-labs.com
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: [SIP] I-D ACTION:draft-ietf-sip-isup-mime-07.txt
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 23 Jan 2001 07:34:43 -0500

--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		: MIME media types for ISUP and QSIG Objects
	Author(s)	: E. Zimmerer, J. Peterson, A. Vemuri,
                          L. Ong, M. Watson, M. Zonoun
	Filename	: draft-ietf-sip-isup-mime-07.txt
	Pages		: 7
	Date		: 22-Jan-01
	
This document describes MIME types for application/ISUP and 
application/QSIG objects for use in SIP applications, according to 
the rules defined in RFC 2048 [1].  These types can be used to identify 
ISUP and QSIG objects within a SIP message such as INVITE or INFO, 
as might be implemented when using SIP between legacy systems.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-mime-07.txt

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-isup-mime-07.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-isup-mime-07.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:	<20010122143550.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-sip-isup-mime-07.txt

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

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

--OtherAccess--

--NextPart--



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 23 10:12:59 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14337
	for <sip-archive@odin.ietf.org>; Tue, 23 Jan 2001 10:12:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3B7EB44339; Tue, 23 Jan 2001 09:13:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id 039DB44336
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 09:12:21 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 23 Jan 2001 15:12:08 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id PAA06547; Tue, 23 Jan 2001 15:10:53 GMT
Message-ID: <3A6D9EFC.25AE62B7@ubiquity.net>
From: Neil Deason <ndeason@ubiquity.net>
Organization: Ubiquity Software Corporation Limited
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Rohan Mahy <rohan@cisco.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Agenda/location for Interim meeting
References: <4.1.20010122214224.00b63850@imop.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 23 Jan 2001 15:10:52 +0000
Content-Transfer-Encoding: 7bit

Can the meeting's minutes as well as all presentations be made 
available please. Has there been any thought on how the output 
from this is going to be used? After the previous record route 
discussion Jonathan was generous enough to write up new proposed 
text and post it to this list. Will the presenters here be asked 
to do similar.

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

Rohan Mahy wrote:
> 
> Hi Folks,
> 
> Below is a rough agenda for the interim meeting on Feb 8th and 9th. I've
> asked the relevant folks shown to moderate discussions in each area.  If
> you have a draft or idea you have presented on the list and want to present
> topics/issues, please contact them.  Dean, can you please create a web page
> for the agenda and any relevant drafts/presos?
>
> Presentations should NOT be tutorial in nature and should list the
> issues/choices/differences at hand.  Presentations must conform to the
> usual IETF rules (no logos, etc.).
> 
> Thursday Feb 8th
> 08:00  Logisitics and Agenda Bashing                                    Dean Willis
> 08:30  SUBSCRIBE/NOTIFY (split with presence docs, forking)             Adam Roach
> 11:00  Call Control Models (3pcc vs. phonectl vs. peer-to-peer 3pcc)    Rohan
> 12:30  Break for Lunch (provided)
> 13:30  REFER issues                                                     Robert Sparks
> 16:30  SIP device configuration                                         Rick Dean
> 17:30  Dinner
> 19:00  SIP conferencing                                         Henning
> 21:00  Stop for the night
> 
> Friday Feb 9th
> 08:00  Base spec open issues: (Record Routing, Early Media, ...)        Jonathan R
> 12:00  Break for Lunch (provided)
> 13:00  Firewall/NAT traversal                                           Jonathan R
> 15:00  AAA requirements                                         Jon Peterson
> 17:00  Close
> 
> Robert Sparks of Dynamicsoft has volunteered the use of a meeting room at
> their offices:
>         5100 Tennyson Parkway
>         Suite 1200
>         Plano, Texas 75024
> This is a smallish room, so if you show up but didn't tell me that you are
> coming, there probably won't be any chairs/space left.
> 
> Cisco/Rohan will provide a simple lunch (probably sandwiches).
> 
> Directions are available at:
>         http://www.dynamicsoft.com/contact/dynamicsoft_locations.html#Texas Office
> 
> There are many, many hotels within a 5 miles radius.  Several folks appear
> to be staying at the Residence Inn mentioned on the web page above.
> 
> Only 4 people have contacted me asking to call in for the meeting.  Unless
> I hear from more of you in the next few days, I will reserve 6 ports on a
> conference bridge.
> 
> thanks,
> -rohan

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 23 11:29:56 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16685
	for <sip-archive@odin.ietf.org>; Tue, 23 Jan 2001 11:29:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5DB744434A; Tue, 23 Jan 2001 10:30:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from rainier.illuminet.com (unknown [63.116.20.4])
	by lists.bell-labs.com (Postfix) with ESMTP id 86B9944336
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 10:29:54 -0500 (EST)
Received: from olwinexsmtp01.corp.illuminet.com ([172.20.1.9]) by rainier.illuminet.com (8.8.8/8.8.8) with ESMTP id IAA25401 for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 08:29:41 -0800 (PST)
Received: by olwinexsmtp01.corp.illuminet.com with Internet Mail Service (5.5.2653.19)
	id <DPHV0GCV>; Tue, 23 Jan 2001 08:29:41 -0800
Message-ID: <1C1EEC765F843E44996971A80682118B2523F0@OPWINEXCL01>
From: Kevin McCandless <KMcCandless@illuminet.com>
To: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
Subject: FW: [SIP] Routing of SIP calls
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 23 Jan 2001 08:29:39 -0800

I would appreciate some help with my questions.  I am new to IETF and SIP.
Also, is there a document that spells out answers to my questions??

-----Original Message-----
From: Kevin McCandless [mailto:KMcCandless@illuminet.com]
Sent: Monday, January 22, 2001 2:25 PM
To: sip@lists.bell-labs.com
Subject: [SIP] Routing of SIP calls


Hello Everyone:

Can someone explain these two routing scenarios of SIP calls for me.  

1.  The first would be SIP1 calls SIP2 and neither party has moved.  In this
example, how does SIP1 find SIP2?   

2.  The second would be SIP1 calls SIP2 but SIP2 has moved.  In this
example, how does SIP1 find SIP2?   

Also, would the ENUM proposed databases be involved in the routing for
either scenario?

Sincerely,

Kevin McCandless
Senior Network Planner
Illuminet
913-814-6397
kmccandles@illuminet.com


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 23 11:39:54 2001
Received: from lists.bell-labs.com ([204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16948
	for <sip-archive@odin.ietf.org>; Tue, 23 Jan 2001 11:39:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DAC5D4438A; Tue, 23 Jan 2001 10:40:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by lists.bell-labs.com (Postfix) with ESMTP id A27F344336
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 10:39:05 -0500 (EST)
Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16])
	by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA27380
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 11:38:32 -0500 (EST)
Received: from cisco.com (rtp-xdm1.cisco.com [64.102.17.80])
	by dingdong.cisco.com (Mirapoint)
	with ESMTP id AAL36532 (AUTH shbhatna);
	Tue, 23 Jan 2001 11:38:50 -0500 (EST)
Message-ID: <3A6DB399.802ED2E1@cisco.com>
From: Shail Bhatnagar <shbhatna@cisco.com>
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: sip@lists.bell-labs.com
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Escaped characters in sip/tel URLs
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 23 Jan 2001 11:38:49 -0500
Content-Transfer-Encoding: 7bit

I am trying to understand how a proxy or UA would handle
escaped characters in sip/tel URLs and what are its uses. 
Are you supposed to unescape those characters in the 
parsed form and re-escape them when generating the 
unparsed form ? I understand it provides a mechanism to
put illegal characters but what is the real use of this
feature. Can somebody provide some  examples ?
I see one example on page 29 of rfc2543bis-02.ps, according
to which the To header of the REGISTER request would look
like this :

To: alice%40wonderland.com@example.com
         ^^^ ( note the '@' sign in the user portion).

Does it mean that proxy/registrar at example.com would 
actually save alice@wonderland.com as the search key/user
portion of this registration. 



Thanks,
Shail

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 23 11:47:14 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17149
	for <sip-archive@odin.ietf.org>; Tue, 23 Jan 2001 11:47:14 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E7D7244393; Tue, 23 Jan 2001 10:47:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26])
	by lists.bell-labs.com (Postfix) with ESMTP id 1D10644392
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 10:46:14 -0500 (EST)
Received: from esvir07nok.ntc.nokia.com (esvir07nokt.ntc.nokia.com [172.21.143.39])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0NGkBJ09096
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 18:46:11 +0200 (EET)
Received: from esebh02nok.ntc.nokia.com (unverified) by esvir07nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T514962c2bdac158f27115@esvir07nok.ntc.nokia.com>;
 Tue, 23 Jan 2001 18:46:00 +0200
Received: by esebh02nok with Internet Mail Service (5.5.2652.78)
	id <C0KG5V64>; Tue, 23 Jan 2001 18:45:59 +0200
Message-ID: <EF9802A00654D411934E00508BAD76CC1000CE@eseis13nok.ntc.nokia.com>
From: aki.niemi@nokia.com
To: KMcCandless@illuminet.com
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Routing of SIP calls
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 23 Jan 2001 18:45:59 +0200

Hi,

These things are handled by SIP servers, namely proxy, registrar and
redirect. Users simply REGISTER to a registrar, which makes a pointer from
your well known SIP URL, e.g., <sip:kmccandles@illuminet.com> to your
current location (IP-address). 

People call <sip:kmccandles@illuminet.com>, and the SIP proxy/redirect
server at illuminet.com takes care of the messages from there on.

For further info, see RFC2543 and http://www.cs.columbia.edu/~hgs/sip/, they
are good starting points.

Cheers,
Aki


> I would appreciate some help with my questions.  I am new to 
> IETF and SIP.
> Also, is there a document that spells out answers to my questions??
> 
> -----Original Message-----
> From: Kevin McCandless [mailto:KMcCandless@illuminet.com]
> Sent: Monday, January 22, 2001 2:25 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Routing of SIP calls
> 
> 
> Hello Everyone:
> 
> Can someone explain these two routing scenarios of SIP calls for me.  
> 
> 1.  The first would be SIP1 calls SIP2 and neither party has 
> moved.  In this
> example, how does SIP1 find SIP2?   
> 
> 2.  The second would be SIP1 calls SIP2 but SIP2 has moved.  In this
> example, how does SIP1 find SIP2?   
> 
> Also, would the ENUM proposed databases be involved in the routing for
> either scenario?
> 
> Sincerely,
> 
> Kevin McCandless
> Senior Network Planner
> Illuminet
> 913-814-6397
> kmccandles@illuminet.com
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 23 12:05:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17899
	for <sip-archive@odin.ietf.org>; Tue, 23 Jan 2001 12:05:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5F05F44387; Tue, 23 Jan 2001 11:06:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 1787F44385
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 11:05:34 -0500 (EST)
Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0NH5GK23237;
	Tue, 23 Jan 2001 11:05:16 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f0NH1af09777;
	Tue, 23 Jan 2001 11:01:36 -0600 (CST)
Received: from ericsson.com (pc050184.exu.ericsson.se [138.85.50.184]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA11716; Tue, 23 Jan 2001 11:05:15 -0600 (CST)
Message-ID: <3A6DB9A2.6090404@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Shail Bhatnagar <shbhatna@cisco.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Escaped characters in sip/tel URLs
References: <3A6DB399.802ED2E1@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 23 Jan 2001 11:04:34 -0600
Content-Transfer-Encoding: 7bit


Shail Bhatnagar wrote:

> I am trying to understand how a proxy or UA would handle
> escaped characters in sip/tel URLs and what are its uses. 
> Are you supposed to unescape those characters in the 
> parsed form and re-escape them when generating the 
> unparsed form ? 

Yes.

> I understand it provides a mechanism to
> put illegal characters but what is the real use of this
> feature. Can somebody provide some  examples ?

The whole point is to allow someone else define
how they will use the fields of the URI and what
information they will put in them. In a word,
extensibility.

> I see one example on page 29 of rfc2543bis-02.ps, according
> to which the To header of the REGISTER request would look
> like this :
> 
> To: alice%40wonderland.com@example.com
>          ^^^ ( note the '@' sign in the user portion).
> 
> Does it mean that proxy/registrar at example.com would 
> actually save alice@wonderland.com as the search key/user
> portion of this registration. 

Yes. Note that is it also legal to escape
characters that can legally appear unescaped.
For this reason, you will also need to unescape
the user portion, for instance, before doing
comparisons, sorts, storing, etc.

 
> Thanks,
> Shail

/sean



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 23 13:37:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20499
	for <sip-archive@odin.ietf.org>; Tue, 23 Jan 2001 13:37:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 25E7E44369; Tue, 23 Jan 2001 12:38:05 -0500 (EST)
Delivered-To: sip@share.research.bell-labs.com
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by lists.bell-labs.com (Postfix) with SMTP id DD36544336
	for <sip@share.research.bell-labs.com>; Tue, 23 Jan 2001 12:37:35 -0500 (EST)
Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Jan 23 13:35:08 EST 2001
Received: by lists.bell-labs.com (Postfix)
	id A1DBA44380; Tue, 23 Jan 2001 13:23:20 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5])
	by lists.bell-labs.com (Postfix) with SMTP id 4F5F64437D
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 13:23:20 -0500 (EST)
Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id MAA09725; Tue, 23 Jan 2001 12:23:15 -0600
Cc: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2)
	id MAA09673; Tue, 23 Jan 2001 12:23:13 -0600
Message-ID: <3A6DCC12.720E1F54@lucent.com>
From: Vijay Gurbani <vkg@lucent.com>
Organization: Lucent Technologies/Bell Laboratories
X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kevin McCandless <KMcCandless@illuminet.com>
Original-CC: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
Subject: Re: FW: [SIP] Routing of SIP calls
References: <1C1EEC765F843E44996971A80682118B2523F0@OPWINEXCL01>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 23 Jan 2001 12:23:14 -0600
Content-Transfer-Encoding: 7bit

Kevin McCandless wrote:
[...]
> Hello Everyone:
> 
> Can someone explain these two routing scenarios of SIP calls for me.
> 
> 1.  The first would be SIP1 calls SIP2 and neither party has moved.  In 
> this example, how does SIP1 find SIP2?

Depends on many factors; but for the most part DNS lookups.  See the steps
in the bis draft, Section 1.4.2.
 
> 2.  The second would be SIP1 calls SIP2 but SIP2 has moved.  In this
> example, how does SIP1 find SIP2?

Again, depends on many factors.  Easiest explanation is that when SIP2 
moved, he/she re-registered the new location with the Registrar and SIP1
queried the Registrar (through a SIP Proxy/Redirect server) to find out the
new location.

> Also, would the ENUM proposed databases be involved in the routing for
> either scenario?

Could be; so could SIP CGI, CPL, TRIP, ...

Hope that helps.  If you have follow-up questions, you may want to post them 
to the SIP IMPLEMENTORS list (sip-implementors@cs.columbia.edu)

Regards,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group 
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 23 14:18:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21983
	for <sip-archive@odin.ietf.org>; Tue, 23 Jan 2001 14:18:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 739684439C; Tue, 23 Jan 2001 13:19:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail.mediatrix.com (mail.mediatrix.com [205.237.248.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 74C6144336
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 13:18:47 -0500 (EST)
Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21)
	id <C66HQYMZ>; Tue, 23 Jan 2001 14:17:50 -0500
Message-ID: <F1BED55F35F4D3118C0F00E0295CFF4D6468F3@mail.mediatrix.com>
From: Eric Tremblay <etremblay@mediatrix.com>
To: "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] T2 and 182 Queued
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 23 Jan 2001 14:17:49 -0500

David,

10.3.1 states that INVITES are retransmitted after T1 seconds, and this
value doubles after each retransmission.  Retransmissions are stopped when
receiving any kind of response (provisional or definitive).  As soon as a
UAC receives a 182, it simply stops retransmitting its INVITE and waits for
a final response (which can take a lot of time to come).

EricT



> -----Original Message-----
> From: David Frascone [mailto:dave@frascone.com]
> Sent: Monday, January 22, 2001 12:47
> To: sip@lists.bell-labs.com
> Subject: Re: [SIP] T2 and 182 Queued
> 
> 
> You are right.  I did copy the wrong paragraph.  But, I still 
> can't find 
> anywhere in 10.3 that stops the T2 timer.  It says that 
> provisional responses
> are re-sent upon every duplicate request, but it never resets 
> the T2 timer.
> 
> My concern is not retransmissions, but the total call setup 
> time, which 
> could take much longer than T2 allows, if the call is queued.
> 
> Now, if the timers are just a suggestion, and the user agent 
> can do whatever
> it wants, then this is not a problem.  I know that I can set 
> T1 and T2 to
> whatever values I want, but I'd prefer to have a queued call 
> work within
> the "suggested" parameters of 500ms and 4sec as set by the RFC.
> 
> Comments?  Does anyone really care?  Should I ignore this, 
> and just set my
> T2 timer really high?
> 
> 
> 
> On Mon, Jan 22, 2001 at 05:29:45PM -0000, Jo Hornsby wrote:
> > David Frascone wrote:
> > > Given this forwarded discussion, this might be an error in 02bis.
> > 
> > It might be.  But given the fact that section 10.2 is entitled:
> > "Reliability for Requests Other Than INVITE", I suspect it 
> is not. &:)
> > 
> > > ----- Forwarded message from Jo Hornsby 
> <jhornsby@ubiquity.net> -----
> > > 
> > > From: "Jo Hornsby" <jhornsby@ubiquity.net>
> > > To: "David Frascone" <dave@frascone.com>, 
> > > <sip-implementors@cs.columbia.edu>
> > > Subject: RE: [SIP] T2 and 182 Queued
> > > Date: Mon, 22 Jan 2001 15:47:36 -0000
> > > Message-ID: <000001c0848a$a4281f20$4e34c3c1@ubiquity.co.uk>
> > > 
> > > David Frascone wrote:
> > > >
> > > > Does anyone know the answer to this?  Should I switch 
> to the sip list?
> > > >
> > > >
> > > > On Fri, Jan 19, 2001 at 11:16:13AM -0600, David Frascone wrote:
> > > > > From section 10.2.1:
> > > > >
> > > > >    Subsequent retransmissions are spaced by T2 
> seconds. If the client
> > > > >    receives a provisional response, it continues to 
> retransmit the
> > > > >    request, but with an interval of T2 seconds. 
> Retransmissions cease
> > > > >    when the client has sent a total of eleven 
> packets, or receives a
> > > > >    definitive response. Default values for T1 and T2 are 500 
> > > ms and 4 s,
> > > > >    respectively. Clients MAY use larger values, but 
> SHOULDNOT use
> > > > >    smaller ones. Servers retransmit the response upon 
> receipt of a
> > > > >
> > > > > Which means, the INVITE would be retransmitted every 4 seconds
> > > > > while the caller is waiting in the queue.  And, would 
> stop after
> > > > > 11 retransmissions, or 44 seconds, which is still too 
> small for
> > > > > some queues.
> > > 
> > > You are correct -- the text you quoted does say this.  However,
> > > if you seek to the beginning of the same paragraph, you find:
> > > 
> > >    A SIP client using an unreliable transport protocol such as UDP
> > >    SHOULD retransmit requests other than INVITE or ACK [...]
> > > 
> > > Look to section 10.3 for reliability-related behaviour 
> for INVITEs.
> > > 
> > > 
> > >  - Jo.
> > > 
> > > 
> > > ----- End forwarded message -----
> > > 
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementer's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > "subscribe sip-implementors" in the body.
> > > 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 23 14:39:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22555
	for <sip-archive@odin.ietf.org>; Tue, 23 Jan 2001 14:39:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DAF56443A1; Tue, 23 Jan 2001 13:40:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id 0B2C344336
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 13:39:24 -0500 (EST)
Received: (qmail 30831 invoked by uid 500); 23 Jan 2001 19:44:16 -0000
From: David Frascone <dave@frascone.com>
To: sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
Message-ID: <20010123134415.A30800@newman.frascone.com>
Mail-Followup-To: sip@lists.bell-labs.com
References: <F1BED55F35F4D3118C0F00E0295CFF4D6468F3@mail.mediatrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <F1BED55F35F4D3118C0F00E0295CFF4D6468F3@mail.mediatrix.com>; from etremblay@mediatrix.com on Tue, Jan 23, 2001 at 02:17:49PM -0500
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 23 Jan 2001 13:44:15 -0600

So, a proxy server would just retransmit the 182 indefinately?  I thought the
proxy retransmission timer was also tied to T2.

Hehe, maybe I should just use TCP :)

On Tue, Jan 23, 2001 at 02:17:49PM -0500, Eric Tremblay wrote:
> David,
> 
> 10.3.1 states that INVITES are retransmitted after T1 seconds, and this
> value doubles after each retransmission.  Retransmissions are stopped when
> receiving any kind of response (provisional or definitive).  As soon as a
> UAC receives a 182, it simply stops retransmitting its INVITE and waits for
> a final response (which can take a lot of time to come).
> 
> EricT
> 
> 
> 
> > -----Original Message-----
> > From: David Frascone [mailto:dave@frascone.com]
> > Sent: Monday, January 22, 2001 12:47
> > To: sip@lists.bell-labs.com
> > Subject: Re: [SIP] T2 and 182 Queued
> > 
> > 
> > You are right.  I did copy the wrong paragraph.  But, I still 
> > can't find 
> > anywhere in 10.3 that stops the T2 timer.  It says that 
> > provisional responses
> > are re-sent upon every duplicate request, but it never resets 
> > the T2 timer.
> > 
> > My concern is not retransmissions, but the total call setup 
> > time, which 
> > could take much longer than T2 allows, if the call is queued.
> > 
> > Now, if the timers are just a suggestion, and the user agent 
> > can do whatever
> > it wants, then this is not a problem.  I know that I can set 
> > T1 and T2 to
> > whatever values I want, but I'd prefer to have a queued call 
> > work within
> > the "suggested" parameters of 500ms and 4sec as set by the RFC.
> > 
> > Comments?  Does anyone really care?  Should I ignore this, 
> > and just set my
> > T2 timer really high?
> > 
> > 
> > 
> > On Mon, Jan 22, 2001 at 05:29:45PM -0000, Jo Hornsby wrote:
> > > David Frascone wrote:
> > > > Given this forwarded discussion, this might be an error in 02bis.
> > > 
> > > It might be.  But given the fact that section 10.2 is entitled:
> > > "Reliability for Requests Other Than INVITE", I suspect it 
> > is not. &:)
> > > 
> > > > ----- Forwarded message from Jo Hornsby 
> > <jhornsby@ubiquity.net> -----
> > > > 
> > > > From: "Jo Hornsby" <jhornsby@ubiquity.net>
> > > > To: "David Frascone" <dave@frascone.com>, 
> > > > <sip-implementors@cs.columbia.edu>
> > > > Subject: RE: [SIP] T2 and 182 Queued
> > > > Date: Mon, 22 Jan 2001 15:47:36 -0000
> > > > Message-ID: <000001c0848a$a4281f20$4e34c3c1@ubiquity.co.uk>
> > > > 
> > > > David Frascone wrote:
> > > > >
> > > > > Does anyone know the answer to this?  Should I switch 
> > to the sip list?
> > > > >
> > > > >
> > > > > On Fri, Jan 19, 2001 at 11:16:13AM -0600, David Frascone wrote:
> > > > > > From section 10.2.1:
> > > > > >
> > > > > >    Subsequent retransmissions are spaced by T2 
> > seconds. If the client
> > > > > >    receives a provisional response, it continues to 
> > retransmit the
> > > > > >    request, but with an interval of T2 seconds. 
> > Retransmissions cease
> > > > > >    when the client has sent a total of eleven 
> > packets, or receives a
> > > > > >    definitive response. Default values for T1 and T2 are 500 
> > > > ms and 4 s,
> > > > > >    respectively. Clients MAY use larger values, but 
> > SHOULDNOT use
> > > > > >    smaller ones. Servers retransmit the response upon 
> > receipt of a
> > > > > >
> > > > > > Which means, the INVITE would be retransmitted every 4 seconds
> > > > > > while the caller is waiting in the queue.  And, would 
> > stop after
> > > > > > 11 retransmissions, or 44 seconds, which is still too 
> > small for
> > > > > > some queues.
> > > > 
> > > > You are correct -- the text you quoted does say this.  However,
> > > > if you seek to the beginning of the same paragraph, you find:
> > > > 
> > > >    A SIP client using an unreliable transport protocol such as UDP
> > > >    SHOULD retransmit requests other than INVITE or ACK [...]
> > > > 
> > > > Look to section 10.3 for reliability-related behaviour 
> > for INVITEs.
> > > > 
> > > > 
> > > >  - Jo.
> > > > 
> > > > 
> > > > ----- End forwarded message -----
> > > > 
> > > > _______________________________________________
> > > > This list is for continuing development of the SIP protocol.
> > > > The sip-implementer's list is the place to discuss implementation,
> > > > and to receive advice on understanding existing sip.
> > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > > "subscribe sip-implementors" in the body.
> > > > 
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> > 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 23 15:55:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24388
	for <sip-archive@odin.ietf.org>; Tue, 23 Jan 2001 15:55:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 913CE443A0; Tue, 23 Jan 2001 14:56:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id 841A744336
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 14:55:50 -0500 (EST)
Received: from cowboys (IDENT:root@localhost [127.0.0.1])
	by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id OAA02779;
	Tue, 23 Jan 2001 14:55:04 -0600
Message-ID: <003201c0857e$5552b0f0$ea036e3f@dynamicsoft.com>
From: "Dean Willis" <dean.willis@softarmor.com>
To: "Neil Deason" <ndeason@ubiquity.net>, "Rohan Mahy" <rohan@cisco.com>
Cc: <sip@lists.bell-labs.com>
References: <4.1.20010122214224.00b63850@imop.cisco.com> <3A6D9EFC.25AE62B7@ubiquity.net>
Subject: Re: [SIP] Agenda/location for Interim meeting
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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 23 Jan 2001 14:20:46 -0600
Content-Transfer-Encoding: 7bit

I have started to accumulate info on the January interim meeting at:

http://www.softarmor.com/sipwg/meets/interim-jan-01/index.html


It will be treated as previous interim meetings, with posted minutes, etc.

--
Dean Willis
SIP WG CoCHair.

----- Original Message -----
From: "Neil Deason" <ndeason@ubiquity.net>
To: "Rohan Mahy" <rohan@cisco.com>
Cc: <sip@lists.bell-labs.com>
Sent: Tuesday, January 23, 2001 9:10 AM
Subject: Re: [SIP] Agenda/location for Interim meeting


> Can the meeting's minutes as well as all presentations be made
> available please. Has there been any thought on how the output
> from this is going to be used? After the previous record route
> discussion Jonathan was generous enough to write up new proposed
> text and post it to this list. Will the presenters here be asked
> to do similar.
>
> Cheers,
> Neil.
> --
> Ubiquity Software Corporation, UK        http://www.ubiquity.net
>
> Rohan Mahy wrote:
> >
> > Hi Folks,
> >
> > Below is a rough agenda for the interim meeting on Feb 8th and 9th. I've
> > asked the relevant folks shown to moderate discussions in each area.  If
> > you have a draft or idea you have presented on the list and want to
present
> > topics/issues, please contact them.  Dean, can you please create a web
page
> > for the agenda and any relevant drafts/presos?
> >
> > Presentations should NOT be tutorial in nature and should list the
> > issues/choices/differences at hand.  Presentations must conform to the
> > usual IETF rules (no logos, etc.).
> >
> > Thursday Feb 8th
> > 08:00  Logisitics and Agenda Bashing
Dean Willis
> > 08:30  SUBSCRIBE/NOTIFY (split with presence docs, forking)
Adam Roach
> > 11:00  Call Control Models (3pcc vs. phonectl vs. peer-to-peer 3pcc)
Rohan
> > 12:30  Break for Lunch (provided)
> > 13:30  REFER issues
Robert Sparks
> > 16:30  SIP device configuration
Rick Dean
> > 17:30  Dinner
> > 19:00  SIP conferencing                                         Henning
> > 21:00  Stop for the night
> >
> > Friday Feb 9th
> > 08:00  Base spec open issues: (Record Routing, Early Media, ...)
Jonathan R
> > 12:00  Break for Lunch (provided)
> > 13:00  Firewall/NAT traversal
Jonathan R
> > 15:00  AAA requirements                                         Jon
Peterson
> > 17:00  Close
> >
> > Robert Sparks of Dynamicsoft has volunteered the use of a meeting room
at
> > their offices:
> >         5100 Tennyson Parkway
> >         Suite 1200
> >         Plano, Texas 75024
> > This is a smallish room, so if you show up but didn't tell me that you
are
> > coming, there probably won't be any chairs/space left.
> >
> > Cisco/Rohan will provide a simple lunch (probably sandwiches).
> >
> > Directions are available at:
> >
http://www.dynamicsoft.com/contact/dynamicsoft_locations.html#Texas Office
> >
> > There are many, many hotels within a 5 miles radius.  Several folks
appear
> > to be staying at the Residence Inn mentioned on the web page above.
> >
> > Only 4 people have contacted me asking to call in for the meeting.
Unless
> > I hear from more of you in the next few days, I will reserve 6 ports on
a
> > conference bridge.
> >
> > thanks,
> > -rohan
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
>


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 23 18:48:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26562
	for <sip-archive@odin.ietf.org>; Tue, 23 Jan 2001 18:48:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 45FC34433D; Tue, 23 Jan 2001 17:49:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id BFD6044336
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 17:48:50 -0500 (EST)
Received: from cowboys (IDENT:root@localhost [127.0.0.1])
	by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id RAA03215
	for <sip@lists.bell-labs.com>; Tue, 23 Jan 2001 17:48:23 -0600
Message-ID: <006501c08596$8b4a39e0$ea036e3f@dynamicsoft.com>
From: "Dean Willis" <dean.willis@softarmor.com>
To: <sip@lists.bell-labs.com>
References: <4.1.20010122214224.00b63850@imop.cisco.com> <3A6D9EFC.25AE62B7@ubiquity.net> <003201c0857e$5552b0f0$ea036e3f@dynamicsoft.com>
Subject: Re: [SIP] Agenda/location for Interim meeting
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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 23 Jan 2001 17:45:18 -0600
Content-Transfer-Encoding: 7bit


Err, that would in fact be the February interim meeting.

I am rather calendar-challenged since this whole is the millenium 0-index or
1-index debate. I've decided there should be a new month 0 occuring before
January, but I'm not sure what to do with December ;-).

The correct URL is in fact:

http://www.softarmor.com/sipwg/meets/interim-feb-01/index.html

--
Dean

----- Original Message -----
From: "Dean Willis" <dean.willis@softarmor.com>
To: "Neil Deason" <ndeason@ubiquity.net>; "Rohan Mahy" <rohan@cisco.com>
Cc: <sip@lists.bell-labs.com>
Sent: Tuesday, January 23, 2001 2:20 PM
Subject: Re: [SIP] Agenda/location for Interim meeting


> I have started to accumulate info on the January interim meeting at:
>
> http://www.softarmor.com/sipwg/meets/interim-jan-01/index.html
>
>
> It will be treated as previous interim meetings, with posted minutes, etc.
>
> --
> Dean Willis
> SIP WG CoCHair.
>
> ----- Original Message -----
> From: "Neil Deason" <ndeason@ubiquity.net>
> To: "Rohan Mahy" <rohan@cisco.com>
> Cc: <sip@lists.bell-labs.com>
> Sent: Tuesday, January 23, 2001 9:10 AM
> Subject: Re: [SIP] Agenda/location for Interim meeting
>
>
> > Can the meeting's minutes as well as all presentations be made
> > available please. Has there been any thought on how the output
> > from this is going to be used? After the previous record route
> > discussion Jonathan was generous enough to write up new proposed
> > text and post it to this list. Will the presenters here be asked
> > to do similar.
> >
> > Cheers,
> > Neil.
> > --
> > Ubiquity Software Corporation, UK        http://www.ubiquity.net
> >
> > Rohan Mahy wrote:
> > >
> > > Hi Folks,
> > >
> > > Below is a rough agenda for the interim meeting on Feb 8th and 9th.
I've
> > > asked the relevant folks shown to moderate discussions in each area.
If
> > > you have a draft or idea you have presented on the list and want to
> present
> > > topics/issues, please contact them.  Dean, can you please create a web
> page
> > > for the agenda and any relevant drafts/presos?
> > >
> > > Presentations should NOT be tutorial in nature and should list the
> > > issues/choices/differences at hand.  Presentations must conform to the
> > > usual IETF rules (no logos, etc.).
> > >
> > > Thursday Feb 8th
> > > 08:00  Logisitics and Agenda Bashing
> Dean Willis
> > > 08:30  SUBSCRIBE/NOTIFY (split with presence docs, forking)
> Adam Roach
> > > 11:00  Call Control Models (3pcc vs. phonectl vs. peer-to-peer 3pcc)
> Rohan
> > > 12:30  Break for Lunch (provided)
> > > 13:30  REFER issues
> Robert Sparks
> > > 16:30  SIP device configuration
> Rick Dean
> > > 17:30  Dinner
> > > 19:00  SIP conferencing
Henning
> > > 21:00  Stop for the night
> > >
> > > Friday Feb 9th
> > > 08:00  Base spec open issues: (Record Routing, Early Media, ...)
> Jonathan R
> > > 12:00  Break for Lunch (provided)
> > > 13:00  Firewall/NAT traversal
> Jonathan R
> > > 15:00  AAA requirements                                         Jon
> Peterson
> > > 17:00  Close
> > >
> > > Robert Sparks of Dynamicsoft has volunteered the use of a meeting room
> at
> > > their offices:
> > >         5100 Tennyson Parkway
> > >         Suite 1200
> > >         Plano, Texas 75024
> > > This is a smallish room, so if you show up but didn't tell me that you
> are
> > > coming, there probably won't be any chairs/space left.
> > >
> > > Cisco/Rohan will provide a simple lunch (probably sandwiches).
> > >
> > > Directions are available at:
> > >
> http://www.dynamicsoft.com/contact/dynamicsoft_locations.html#Texas Office
> > >
> > > There are many, many hotels within a 5 miles radius.  Several folks
> appear
> > > to be staying at the Residence Inn mentioned on the web page above.
> > >
> > > Only 4 people have contacted me asking to call in for the meeting.
> Unless
> > > I hear from more of you in the next few days, I will reserve 6 ports
on
> a
> > > conference bridge.
> > >
> > > thanks,
> > > -rohan
> >
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> >
>
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
>


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 02:15:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16450
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 02:15:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 05A5144339; Wed, 24 Jan 2001 01:16:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from rwcxch02.clarent.com (unknown [208.205.112.2])
	by lists.bell-labs.com (Postfix) with ESMTP id D64FE44337
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 01:15:43 -0500 (EST)
Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21)
	id <C5XRBY6L>; Tue, 23 Jan 2001 23:14:20 -0800
Received: from rwcjfmule01 (adsl-216-103-84-208.dsl.snfc21.pacbell.net [216.103.84.208]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id C5XRBY6H; Tue, 23 Jan 2001 23:14:04 -0800
From: Jean-Francois Mule <jfmule@clarent.com>
Reply-To: Jean-Francois Mule <jfmule@clarent.com>
To: sip-mib@egroups.com, drwalker@ss8networks.com,
        "'Joon Maeng'" <joon_maeng@vtel.com>
Cc: klingle@cisco.com, sip@lists.bell-labs.com
Message-ID: <005601c085d5$3e6887a0$0100007f@rwcjfmule01>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0057_01C08592.304547A0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Subject: [SIP] [sip mib] work on SIP UA config timers and retries - action item #10
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 23 Jan 2001 23:14:07 -0800

This is a multi-part message in MIME format.

------=_NextPart_000_0057_01C08592.304547A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

In the process of working on timers for stateful sip proxy, find below a
review and update proposal for the sipUACfg config timers and retry.  If we
agree on these changes, those timers will be replicated for the server mib
(case of stateful sip proxy servers).

please, check this and confirm it's ok so that we can make progress on the
proxy side.
Thank you,
Jean-Francois Mule.
-------------------------------------------------------
There are 2 related tables in SIP-UA mib:  sipUACfgTimer and sipUACfgRetry.
Based on the description of the variables, I'd like to propose the following
additions and changes:
	a/ Addition of timers + retry for OPTIONS method in SIP UA only (this is
not in draft-01, but I see no particular reason for not adding it)
	b/ Addition of timers + retry for INFO method (since stats do include INFO
and INFO is an rfc...)
	c/ Naming changes
We should try to keep the same NAMING CONVENTIONS among the objects in those
2 tables. The timer naming rule is:
	timer and retry counters should be named after the associated SIP method
used (invite, ack, bye, ... - see below for example of this).  This renaming
goes along well with the current description fields.
	d/ Addition of default values according to RFC2543 using DEFVAL clause:  I
took 500 ms by default and a total of 6 retries for the SIP INVITE as
specified in section 10.5 of 2543.
	e/ rework the description to mention T1/T2 timers...
As for T1/T2 timers, I think the timers we can specify in the Timer table
are the initial T1 timers (kind of a T1 timer for each method).  There is
*no* specified T2 timer in the current table so I added one object under the
name of sipUACfgTimerT2;  feel free to comment on the name/description.
Took 4s as default T2 timer as per 2543.


Applying all these comments, this is what changes:
0/
	add sipUACfgTimerOptions
	add sipUACfgRetryOptions
	add sipUACfgTimerInfo
	add sipUACfgRetryInfo
	add DEFVAL values
	add sipUACfgTimerT2
	misc: fixed end of description field in sipUACfgTimerRegister
      misc: sipUACfgTimerReRegister had been already renamed into
sipUACfgTimerRegister by Kevin Lingle
1/
	rename sipUACfgTimerTrying into sipUACfgTimerInvite
	keep sipUACfgRetryInvite
2/
	rename sipUACfgTimerDisconnect into sipUACfgTimerBye
	keep  sipUACfgRetryBye
3/
      for sipUACfgRetryResponse, it seems that the description should
specify "final" response (UA does not expect an ACK after a non-final
response).  Added the term "final"  accordingly.
-------------------------------------------------------
-- Here is the ASN.1 with all the changes:
-- syntax to be checked via mib compiler
-------------------------------------------------------
   --
   -- SIP Timer Configuration
   --
   sipUACfgTimerTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SipUACfgTimerEntry
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
            "This table contains timer configuration objects applicable
             to each SIP user agent in this system.  The instances of
             SIP entities are uniquely identified by applIndex."
       ::= { sipUACfgTimer 1 }

   sipUACfgTimerEntry OBJECT-TYPE
       SYNTAX     SipUACfgTimerEntry
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
            "A row of timer configuration."
       INDEX { applIndex }
       ::= { sipUACfgTimerTable 1 }

   SipUACfgTimerEntry ::=
       SEQUENCE {
                sipUACfgTimerInvite        Integer32,
                sipUACfgTimerProv          Integer32,
                sipUACfgTimerAck           Integer32,
                sipUACfgTimerBye           Integer32,
                sipUACfgTimerRegister      Integer32,
                sipUACfgTimerOptions       Integer32,
                sipUACfgTimerInfo          Integer32,
                sipUACfgTimerT2            Integer32
       }

   sipUACfgTimerInvite OBJECT-TYPE
       SYNTAX      Integer32 (100..1000)
       UNITS       "milliseconds"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
            "This object specifies the time a user agent will wait to
             receive a provisional response to an INVITE before
             resending the INVITE."
       DEFVAL { 500 }
       ::= { sipUACfgTimerEntry 1 }

   sipUACfgTimerProv OBJECT-TYPE
       SYNTAX      Integer32 (60000..300000)
       UNITS       "milliseconds"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
            "This object specifies the time a user agent will wait to
             receive a final response to an INVITE before canceling the
             transaction."
       DEFVAL { 500 }
   ::= { sipUACfgTimerEntry 2 }

   sipUACfgTimerAck OBJECT-TYPE
       SYNTAX      Integer32 (100..1000)
       UNITS       "milliseconds"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
            "This object specifies the time a user agent will wait to
             receive an ACK confirmation indicating that a session is
             established."
       DEFVAL { 500 }
       ::= { sipUACfgTimerEntry 3 }

   sipUACfgTimerBye OBJECT-TYPE
       SYNTAX      Integer32 (100..1000)
       UNITS       "milliseconds"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
            "This object specifies the time a user agent will wait to
             receive a BYE confirmation indicating that a session is
             terminated."
       DEFVAL { 500 }
       ::= { sipUACfgTimerEntry 4 }

   sipUACfgTimerRegister OBJECT-TYPE
       SYNTAX      Integer32 (100..1000)
       UNITS       "milliseconds"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
            "This object specifies the time a user agent will wait
             for a response to its REGISTER request before resending."
       DEFVAL { 500 }
       ::= { sipUACfgTimerEntry 5 }

   sipUACfgTimerOptions  OBJECT-TYPE
       SYNTAX      Integer32 (100..1000)
       UNITS       "milliseconds"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
            "This object specifies the time a user agent will wait
             for a response to its OPTIONS request before resending."
       DEFVAL { 500 }
       ::= { sipUACfgTimerEntry 6 }


   sipUACfgTimerInfo  OBJECT-TYPE
       SYNTAX      Integer32 (100..1000)
       UNITS       "milliseconds"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
            "This object specifies the time a user agent will wait
             for a response to its INFO request before resending."
       DEFVAL { 500 }
       ::= { sipUACfgTimerEntry 7 }

   sipUACfgTimerT2  OBJECT-TYPE
       SYNTAX      Integer32 (200..10000)
       UNITS       "milliseconds"
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
            "This object specifies the T2 timer for a user agent."
       REFERENCE "Section 10.4 and 10.5 RFC2543"
       DEFVAL { 4000 }
       ::= { sipUACfgTimerEntry 8 }


   --
   -- SIP Retry Configuration
   --
   sipUACfgRetryTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SipUACfgRetryEntry
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
            "This table contains retry configuration objects applicable
             to each SIP user agent in this system.  The instances of
             SIP entities are uniquely identified by applIndex."
       ::= { sipUACfgRetry 1 }

   sipUACfgRetryEntry OBJECT-TYPE
       SYNTAX     SipUACfgRetryEntry
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
            "A row of retry configuration."
       INDEX { applIndex }
       ::= { sipUACfgRetryTable 1 }

   SipUACfgRetryEntry ::=
       SEQUENCE {
                sipUACfgRetryInvite       Integer32,
                sipUACfgRetryBye          Integer32,
                sipUACfgRetryCancel       Integer32,
                sipUACfgRetryRegister     Integer32,
                sipUACfgRetryResponse     Integer32,
                sipUACfgRetryOptions      Integer32,
                sipUACfgRetryInfo         Integer32
       }

   sipUACfgRetryInvite OBJECT-TYPE
       SYNTAX      Integer32 (1..10)
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
            "This object will specify the number of times a user agent
             will retry sending an INVITE request."
       REFERENCE "Section 10.5 RFC 2543"
	   DEFVAL { 6 }
       ::= { sipUACfgRetryEntry 1 }

   sipUACfgRetryBye OBJECT-TYPE
       SYNTAX      Integer32 (1..10)
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
            "This object will specify the number of times a user agent
             will retry sending a BYE request."
       REFERENCE "Section 10.4 RFC 2543"
       ::= { sipUACfgRetryEntry 2 }

   sipUACfgRetryCancel OBJECT-TYPE
       SYNTAX      Integer32 (1..10)
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
            "This object will specify the number of times a user agent
             will retry sending a CANCEL request."
       REFERENCE "Section 10.4 RFC 2543"
       ::= { sipUACfgRetryEntry 3 }

   sipUACfgRetryRegister OBJECT-TYPE
       SYNTAX      Integer32 (1..10)
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
            "This object will specify the number of times a user agent
             will retry sending a REGISTER request."
       REFERENCE "Section 10.4 RFC 2543"
       ::= { sipUACfgRetryEntry 4 }

   sipUACfgRetryResponse OBJECT-TYPE
       SYNTAX      Integer32 (1..10)
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
            "This object will specify the number of times a user agent
             will retry sending a final response and expecting an ACK."
       ::= { sipUACfgRetryEntry 5 }

   sipUACfgRetryOptions OBJECT-TYPE
       SYNTAX      Integer32 (1..10)
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
            "This object will specify the number of times a user agent
             will retry sending an OPTIONS request."
       REFERENCE "Section 10.4 RFC2543"
       ::= { sipUACfgRetryEntry 6 }


   sipUACfgRetryInfo OBJECT-TYPE
       SYNTAX      Integer32 (1..10)
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
            "This object will specify the number of times a user agent
             will retry sending an INFO request."
       REFERENCE "Section 2.4 RFC 2976"
       ::= { sipUACfgRetryEntry 7 }


------=_NextPart_000_0057_01C08592.304547A0
Content-Type: application/octet-stream;
	name="SIP-UA-MIB timers.my"
Content-Disposition: attachment;
	filename="SIP-UA-MIB timers.my"
Content-Transfer-Encoding: 7bit


   -- 
   -- SIP Timer Configuration 
   -- 
   sipUACfgTimerTable OBJECT-TYPE 
       SYNTAX      SEQUENCE OF SipUACfgTimerEntry 
       MAX-ACCESS not-accessible 
       STATUS     current 
       DESCRIPTION 
            "This table contains timer configuration objects applicable  
             to each SIP user agent in this system.  The instances of  
             SIP entities are uniquely identified by applIndex." 
       ::= { sipUACfgTimer 1 } 
    
   sipUACfgTimerEntry OBJECT-TYPE 
       SYNTAX     SipUACfgTimerEntry 
       MAX-ACCESS not-accessible 
       STATUS     current 
       DESCRIPTION 
            "A row of timer configuration." 
       INDEX { applIndex } 
       ::= { sipUACfgTimerTable 1 } 
    
   SipUACfgTimerEntry ::= 
       SEQUENCE { 
                sipUACfgTimerInvite        Integer32, 
                sipUACfgTimerProv          Integer32, 
                sipUACfgTimerAck           Integer32, 
                sipUACfgTimerBye           Integer32, 
                sipUACfgTimerRegister      Integer32,
                sipUACfgTimerOptions       Integer32,
                sipUACfgTimerInfo          Integer32,
                sipUACfgTimerT2            Integer32
       } 
    
   sipUACfgTimerInvite OBJECT-TYPE 
       SYNTAX      Integer32 (100..1000) 
       UNITS       "milliseconds" 
       MAX-ACCESS  read-write 
       STATUS      current 
       DESCRIPTION 
            "This object specifies the time a user agent will wait to 
             receive a provisional response to an INVITE before 
             resending the INVITE." 
       DEFVAL { 500 } 
       ::= { sipUACfgTimerEntry 1 } 
    
   sipUACfgTimerProv OBJECT-TYPE 
       SYNTAX      Integer32 (60000..300000) 
       UNITS       "milliseconds" 
       MAX-ACCESS  read-write 
       STATUS      current 
       DESCRIPTION 
            "This object specifies the time a user agent will wait to 
             receive a final response to an INVITE before canceling the 
             transaction." 
       DEFVAL { 500 } 
   ::= { sipUACfgTimerEntry 2 } 
    
   sipUACfgTimerAck OBJECT-TYPE 
       SYNTAX      Integer32 (100..1000) 
       UNITS       "milliseconds" 
       MAX-ACCESS  read-write 
       STATUS      current 
       DESCRIPTION 
            "This object specifies the time a user agent will wait to 
             receive an ACK confirmation indicating that a session is 
             established." 
       DEFVAL { 500 } 
       ::= { sipUACfgTimerEntry 3 } 
    
   sipUACfgTimerBye OBJECT-TYPE 
       SYNTAX      Integer32 (100..1000) 
       UNITS       "milliseconds" 
       MAX-ACCESS  read-write 
       STATUS      current 
       DESCRIPTION 
            "This object specifies the time a user agent will wait to 
             receive a BYE confirmation indicating that a session is 
             terminated." 
       DEFVAL { 500 } 
       ::= { sipUACfgTimerEntry 4 } 
    
   sipUACfgTimerRegister OBJECT-TYPE 
       SYNTAX      Integer32 (100..1000)
       UNITS       "milliseconds" 
       MAX-ACCESS  read-write 
       STATUS      current 
       DESCRIPTION 
            "This object specifies the time a user agent will wait 
             for a response to its REGISTER request before resending."
       DEFVAL { 500 } 
       ::= { sipUACfgTimerEntry 5 } 

   sipUACfgTimerOptions  OBJECT-TYPE 
       SYNTAX      Integer32 (100..1000)
       UNITS       "milliseconds" 
       MAX-ACCESS  read-write 
       STATUS      current 
       DESCRIPTION 
            "This object specifies the time a user agent will wait 
             for a response to its OPTIONS request before resending."
       DEFVAL { 500 } 
       ::= { sipUACfgTimerEntry 6 } 


   sipUACfgTimerInfo  OBJECT-TYPE 
       SYNTAX      Integer32 (100..1000)
       UNITS       "milliseconds" 
       MAX-ACCESS  read-write 
       STATUS      current 
       DESCRIPTION 
            "This object specifies the time a user agent will wait 
             for a response to its INFO request before resending."
       DEFVAL { 500 } 
       ::= { sipUACfgTimerEntry 7 } 

   sipUACfgTimerT2  OBJECT-TYPE 
       SYNTAX      Integer32 (200..10000)
       UNITS       "milliseconds" 
       MAX-ACCESS  read-write 
       STATUS      current 
       DESCRIPTION 
            "This object specifies the T2 timer for a user agent."
       REFERENCE "Section 10.4 and 10.5 RFC2543"
       DEFVAL { 4000 } 
       ::= { sipUACfgTimerEntry 8 } 


   -- 
   -- SIP Retry Configuration 
   -- 
   sipUACfgRetryTable OBJECT-TYPE 
       SYNTAX      SEQUENCE OF SipUACfgRetryEntry 
       MAX-ACCESS not-accessible 
       STATUS     current 
       DESCRIPTION 
            "This table contains retry configuration objects applicable  
             to each SIP user agent in this system.  The instances of  
             SIP entities are uniquely identified by applIndex." 
       ::= { sipUACfgRetry 1 } 
    
   sipUACfgRetryEntry OBJECT-TYPE 
       SYNTAX     SipUACfgRetryEntry 
       MAX-ACCESS not-accessible 
       STATUS     current 
       DESCRIPTION 
            "A row of retry configuration." 
       INDEX { applIndex } 
       ::= { sipUACfgRetryTable 1 } 
    
   SipUACfgRetryEntry ::= 
       SEQUENCE { 
                sipUACfgRetryInvite       Integer32, 
                sipUACfgRetryBye          Integer32, 
                sipUACfgRetryCancel       Integer32, 
                sipUACfgRetryRegister     Integer32, 
                sipUACfgRetryResponse     Integer32,
                sipUACfgRetryOptions      Integer32,
                sipUACfgRetryInfo         Integer32
       } 
    
   sipUACfgRetryInvite OBJECT-TYPE 
       SYNTAX      Integer32 (1..10) 
       MAX-ACCESS  read-write 
       STATUS      current 
       DESCRIPTION 
            "This object will specify the number of times a user agent 
             will retry sending an INVITE request." 
       REFERENCE "Section 10.5 RFC 2543"
	   DEFVAL { 6 }
       ::= { sipUACfgRetryEntry 1 } 
    
   sipUACfgRetryBye OBJECT-TYPE 
       SYNTAX      Integer32 (1..10) 
       MAX-ACCESS  read-write 
       STATUS      current 
       DESCRIPTION 
            "This object will specify the number of times a user agent 
             will retry sending a BYE request." 
       REFERENCE "Section 10.4 RFC 2543"
       ::= { sipUACfgRetryEntry 2 } 
    
   sipUACfgRetryCancel OBJECT-TYPE 
       SYNTAX      Integer32 (1..10) 
       MAX-ACCESS  read-write 
       STATUS      current 
       DESCRIPTION 
            "This object will specify the number of times a user agent 
             will retry sending a CANCEL request." 
       REFERENCE "Section 10.4 RFC 2543"
       ::= { sipUACfgRetryEntry 3 } 
    
   sipUACfgRetryRegister OBJECT-TYPE 
       SYNTAX      Integer32 (1..10) 
       MAX-ACCESS  read-write 
       STATUS      current 
       DESCRIPTION 
            "This object will specify the number of times a user agent 
             will retry sending a REGISTER request." 
       REFERENCE "Section 10.4 RFC 2543"
       ::= { sipUACfgRetryEntry 4 } 
    
   sipUACfgRetryResponse OBJECT-TYPE 
       SYNTAX      Integer32 (1..10) 
       MAX-ACCESS  read-write 
       STATUS      current 
       DESCRIPTION 
            "This object will specify the number of times a user agent 
             will retry sending a final response and expecting an ACK." 
       ::= { sipUACfgRetryEntry 5 } 

   sipUACfgRetryOptions OBJECT-TYPE 
       SYNTAX      Integer32 (1..10) 
       MAX-ACCESS  read-write 
       STATUS      current 
       DESCRIPTION 
            "This object will specify the number of times a user agent 
             will retry sending an OPTIONS request." 
       REFERENCE "Section 10.4 RFC2543"
       ::= { sipUACfgRetryEntry 6 } 


   sipUACfgRetryInfo OBJECT-TYPE 
       SYNTAX      Integer32 (1..10) 
       MAX-ACCESS  read-write 
       STATUS      current 
       DESCRIPTION 
            "This object will specify the number of times a user agent 
             will retry sending an INFO request." 
       REFERENCE "Section 2.4 RFC 2976"
       ::= { sipUACfgRetryEntry 7 } 


------=_NextPart_000_0057_01C08592.304547A0--

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 04:33:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17182
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 04:33:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B1C9C44346; Wed, 24 Jan 2001 03:34:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from nt-mail.tlv.radvision.com (unknown [212.143.185.30])
	by lists.bell-labs.com (Postfix) with ESMTP id 0DAEE44337
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 03:33:26 -0500 (EST)
Received: by NT-MAIL with Internet Mail Service (5.5.2650.21)
	id <DR51SNDP>; Wed, 24 Jan 2001 11:35:48 +0200
Message-ID: <AA8852B3A8EDD411BFE700508BB82A0B23395A@NT-MAIL>
From: Itamar Gilad <ItamarG@tlv.radvision.com>
To: "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] T2 and 182 Queued
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 11:35:47 +0200

David,

we found that on top of T1 and T2 there's a need for "transaction timeouts"
i.e. a timer that terminates the transaction simply because nothing
significant happened for a given period of time. Note that the durations of
these timeouts vary based on the current state of the transaction. Without
these timeouts some transactions might never die. You can find some
references to this matter in RFC 2543-bis02. 

  Itamar 

> -----Original Message-----
> From: David Frascone [mailto:dave@frascone.com]
> Sent: Tue, January 23, 2001 9:44 PM
> To: sip@lists.bell-labs.com
> Subject: Re: [SIP] T2 and 182 Queued
> 
> 
> So, a proxy server would just retransmit the 182 
> indefinately?  I thought the
> proxy retransmission timer was also tied to T2.
> 
> Hehe, maybe I should just use TCP :)
> 
> On Tue, Jan 23, 2001 at 02:17:49PM -0500, Eric Tremblay wrote:
> > David,
> > 
> > 10.3.1 states that INVITES are retransmitted after T1 
> seconds, and this
> > value doubles after each retransmission.  Retransmissions 
> are stopped when
> > receiving any kind of response (provisional or definitive). 
>  As soon as a
> > UAC receives a 182, it simply stops retransmitting its 
> INVITE and waits for
> > a final response (which can take a lot of time to come).
> > 
> > EricT
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: David Frascone [mailto:dave@frascone.com]
> > > Sent: Monday, January 22, 2001 12:47
> > > To: sip@lists.bell-labs.com
> > > Subject: Re: [SIP] T2 and 182 Queued
> > > 
> > > 
> > > You are right.  I did copy the wrong paragraph.  But, I still 
> > > can't find 
> > > anywhere in 10.3 that stops the T2 timer.  It says that 
> > > provisional responses
> > > are re-sent upon every duplicate request, but it never resets 
> > > the T2 timer.
> > > 
> > > My concern is not retransmissions, but the total call setup 
> > > time, which 
> > > could take much longer than T2 allows, if the call is queued.
> > > 
> > > Now, if the timers are just a suggestion, and the user agent 
> > > can do whatever
> > > it wants, then this is not a problem.  I know that I can set 
> > > T1 and T2 to
> > > whatever values I want, but I'd prefer to have a queued call 
> > > work within
> > > the "suggested" parameters of 500ms and 4sec as set by the RFC.
> > > 
> > > Comments?  Does anyone really care?  Should I ignore this, 
> > > and just set my
> > > T2 timer really high?
> > > 
> > > 
> > > 
> > > On Mon, Jan 22, 2001 at 05:29:45PM -0000, Jo Hornsby wrote:
> > > > David Frascone wrote:
> > > > > Given this forwarded discussion, this might be an 
> error in 02bis.
> > > > 
> > > > It might be.  But given the fact that section 10.2 is entitled:
> > > > "Reliability for Requests Other Than INVITE", I suspect it 
> > > is not. &:)
> > > > 
> > > > > ----- Forwarded message from Jo Hornsby 
> > > <jhornsby@ubiquity.net> -----
> > > > > 
> > > > > From: "Jo Hornsby" <jhornsby@ubiquity.net>
> > > > > To: "David Frascone" <dave@frascone.com>, 
> > > > > <sip-implementors@cs.columbia.edu>
> > > > > Subject: RE: [SIP] T2 and 182 Queued
> > > > > Date: Mon, 22 Jan 2001 15:47:36 -0000
> > > > > Message-ID: <000001c0848a$a4281f20$4e34c3c1@ubiquity.co.uk>
> > > > > 
> > > > > David Frascone wrote:
> > > > > >
> > > > > > Does anyone know the answer to this?  Should I switch 
> > > to the sip list?
> > > > > >
> > > > > >
> > > > > > On Fri, Jan 19, 2001 at 11:16:13AM -0600, David 
> Frascone wrote:
> > > > > > > From section 10.2.1:
> > > > > > >
> > > > > > >    Subsequent retransmissions are spaced by T2 
> > > seconds. If the client
> > > > > > >    receives a provisional response, it continues to 
> > > retransmit the
> > > > > > >    request, but with an interval of T2 seconds. 
> > > Retransmissions cease
> > > > > > >    when the client has sent a total of eleven 
> > > packets, or receives a
> > > > > > >    definitive response. Default values for T1 and 
> T2 are 500 
> > > > > ms and 4 s,
> > > > > > >    respectively. Clients MAY use larger values, but 
> > > SHOULDNOT use
> > > > > > >    smaller ones. Servers retransmit the response upon 
> > > receipt of a
> > > > > > >
> > > > > > > Which means, the INVITE would be retransmitted 
> every 4 seconds
> > > > > > > while the caller is waiting in the queue.  And, would 
> > > stop after
> > > > > > > 11 retransmissions, or 44 seconds, which is still too 
> > > small for
> > > > > > > some queues.
> > > > > 
> > > > > You are correct -- the text you quoted does say this. 
>  However,
> > > > > if you seek to the beginning of the same paragraph, you find:
> > > > > 
> > > > >    A SIP client using an unreliable transport 
> protocol such as UDP
> > > > >    SHOULD retransmit requests other than INVITE or ACK [...]
> > > > > 
> > > > > Look to section 10.3 for reliability-related behaviour 
> > > for INVITEs.
> > > > > 
> > > > > 
> > > > >  - Jo.
> > > > > 
> > > > > 
> > > > > ----- End forwarded message -----
> > > > > 
> > > > > _______________________________________________
> > > > > This list is for continuing development of the SIP protocol.
> > > > > The sip-implementer's list is the place to discuss 
> implementation,
> > > > > and to receive advice on understanding existing sip.
> > > > > To subscribe to it, send mail to 
> majordomo@cs.columbia.edu with
> > > > > "subscribe sip-implementors" in the body.
> > > > > 
> > > 
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementer's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > "subscribe sip-implementors" in the body.
> > > 
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 11:37:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24913
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 11:37:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E9C3E44337; Wed, 24 Jan 2001 10:38:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id 6800A44336
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 10:37:17 -0500 (EST)
Received: (qmail 7213 invoked by uid 500); 24 Jan 2001 16:42:30 -0000
From: David Frascone <dave@frascone.com>
To: sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
Message-ID: <20010124104230.B7103@newman.frascone.com>
Mail-Followup-To: sip@lists.bell-labs.com
References: <AA8852B3A8EDD411BFE700508BB82A0B23395A@NT-MAIL>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <AA8852B3A8EDD411BFE700508BB82A0B23395A@NT-MAIL>; from ItamarG@tlv.radvision.com on Wed, Jan 24, 2001 at 11:35:47AM +0200
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 10:42:30 -0600

Ok, but let me get this straight.  This call flow looks like it is broken
with the current RFC.  Let me know if I am wrong.  It seems broken even
without a proxy.  In the following, I'm assuming a 20-30 minute queue wait.
Not unreasonable if you've ever called customer support about a DSL line :)

Ok, Here is a good call:

    UA1                             UA2
     |                               |
     |             INVITE            |
     |------------------------------>|
     |                               |
     |      182 Queue Position 20    |
     |<------------------------------|
     |                               |
     |      182 Queue Position 10    |
     |<------------------------------|
     |                               |
     |      182 Queue Position 1     |
     |<------------------------------|
     |                               |
     |            200 OK F4          |
     |<------------------------------|
     |                               |
     |               ACK             |
     |------------------------------>|
     |                               |
    UA1                             UA2

Everything is happy above.  But, what about this:


    UA1                             UA2
     |                               |
     |             INVITE            |
     |------------------------------>|
     |                               |
     |      182 Queue Position 120   |
     |<------------------------------|
     |                               |
   Here, the UA1 pulls the plug on his computer, drives into a tunnel,
   has a power outage, ISP drops the connection, etc.  No cancel, just
   vanishes.

     |      182 Queue Position 110   |
     |<------------------------------|
     |                               |
     |      182 Queue Position 100   |
     |<------------------------------|
     |                               |
     |      182 Queue Position 1     |
     |<------------------------------|
     |                               |
     |            200 OK F4          |
     |<------------------------------|
     |                               |
     |   UA2 Timer FINALLY times out |
     |                               |
    UA1                             UA2


So, the UA keeps him in the queue, spitting out UDP packets for a LONG
time, without ever knowing that UA1 is no longer on the network.  So, if
T2 *is* used, the timeout is way too short.  If T2 is NOT used, then there
is an big waste of retransmissions for queued calls.  Perhaps PRACK should be
required for long queue times?  There might even be a DOS attack by forging
tons of INVITES to a full queue.

Now do you see the problem?  



On Wed, Jan 24, 2001 at 11:35:47AM +0200, Itamar Gilad wrote:
> David,
> 


On Wed, Jan 24, 2001 at 11:35:47AM +0200, Itamar Gilad wrote:
> David,
> 
> we found that on top of T1 and T2 there's a need for "transaction timeouts"
> i.e. a timer that terminates the transaction simply because nothing
> significant happened for a given period of time. Note that the durations of
> these timeouts vary based on the current state of the transaction. Without
> these timeouts some transactions might never die. You can find some
> references to this matter in RFC 2543-bis02. 
> 
>   Itamar 
> 
> > -----Original Message-----
> > From: David Frascone [mailto:dave@frascone.com]
> > Sent: Tue, January 23, 2001 9:44 PM
> > To: sip@lists.bell-labs.com
> > Subject: Re: [SIP] T2 and 182 Queued
> > 
> > 
> > So, a proxy server would just retransmit the 182 
> > indefinately?  I thought the
> > proxy retransmission timer was also tied to T2.
> > 
> > Hehe, maybe I should just use TCP :)
> > 
> > On Tue, Jan 23, 2001 at 02:17:49PM -0500, Eric Tremblay wrote:
> > > David,
> > > 
> > > 10.3.1 states that INVITES are retransmitted after T1 
> > seconds, and this
> > > value doubles after each retransmission.  Retransmissions 
> > are stopped when
> > > receiving any kind of response (provisional or definitive). 
> >  As soon as a
> > > UAC receives a 182, it simply stops retransmitting its 
> > INVITE and waits for
> > > a final response (which can take a lot of time to come).
> > > 
> > > EricT
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: David Frascone [mailto:dave@frascone.com]
> > > > Sent: Monday, January 22, 2001 12:47
> > > > To: sip@lists.bell-labs.com
> > > > Subject: Re: [SIP] T2 and 182 Queued
> > > > 
> > > > 
> > > > You are right.  I did copy the wrong paragraph.  But, I still 
> > > > can't find 
> > > > anywhere in 10.3 that stops the T2 timer.  It says that 
> > > > provisional responses
> > > > are re-sent upon every duplicate request, but it never resets 
> > > > the T2 timer.
> > > > 
> > > > My concern is not retransmissions, but the total call setup 
> > > > time, which 
> > > > could take much longer than T2 allows, if the call is queued.
> > > > 
> > > > Now, if the timers are just a suggestion, and the user agent 
> > > > can do whatever
> > > > it wants, then this is not a problem.  I know that I can set 
> > > > T1 and T2 to
> > > > whatever values I want, but I'd prefer to have a queued call 
> > > > work within
> > > > the "suggested" parameters of 500ms and 4sec as set by the RFC.
> > > > 
> > > > Comments?  Does anyone really care?  Should I ignore this, 
> > > > and just set my
> > > > T2 timer really high?
> > > > 
> > > > 
> > > > 
> > > > On Mon, Jan 22, 2001 at 05:29:45PM -0000, Jo Hornsby wrote:
> > > > > David Frascone wrote:
> > > > > > Given this forwarded discussion, this might be an 
> > error in 02bis.
> > > > > 
> > > > > It might be.  But given the fact that section 10.2 is entitled:
> > > > > "Reliability for Requests Other Than INVITE", I suspect it 
> > > > is not. &:)
> > > > > 
> > > > > > ----- Forwarded message from Jo Hornsby 
> > > > <jhornsby@ubiquity.net> -----
> > > > > > 
> > > > > > From: "Jo Hornsby" <jhornsby@ubiquity.net>
> > > > > > To: "David Frascone" <dave@frascone.com>, 
> > > > > > <sip-implementors@cs.columbia.edu>
> > > > > > Subject: RE: [SIP] T2 and 182 Queued
> > > > > > Date: Mon, 22 Jan 2001 15:47:36 -0000
> > > > > > Message-ID: <000001c0848a$a4281f20$4e34c3c1@ubiquity.co.uk>
> > > > > > 
> > > > > > David Frascone wrote:
> > > > > > >
> > > > > > > Does anyone know the answer to this?  Should I switch 
> > > > to the sip list?
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Jan 19, 2001 at 11:16:13AM -0600, David 
> > Frascone wrote:
> > > > > > > > From section 10.2.1:
> > > > > > > >
> > > > > > > >    Subsequent retransmissions are spaced by T2 
> > > > seconds. If the client
> > > > > > > >    receives a provisional response, it continues to 
> > > > retransmit the
> > > > > > > >    request, but with an interval of T2 seconds. 
> > > > Retransmissions cease
> > > > > > > >    when the client has sent a total of eleven 
> > > > packets, or receives a
> > > > > > > >    definitive response. Default values for T1 and 
> > T2 are 500 
> > > > > > ms and 4 s,
> > > > > > > >    respectively. Clients MAY use larger values, but 
> > > > SHOULDNOT use
> > > > > > > >    smaller ones. Servers retransmit the response upon 
> > > > receipt of a
> > > > > > > >
> > > > > > > > Which means, the INVITE would be retransmitted 
> > every 4 seconds
> > > > > > > > while the caller is waiting in the queue.  And, would 
> > > > stop after
> > > > > > > > 11 retransmissions, or 44 seconds, which is still too 
> > > > small for
> > > > > > > > some queues.
> > > > > > 
> > > > > > You are correct -- the text you quoted does say this. 
> >  However,
> > > > > > if you seek to the beginning of the same paragraph, you find:
> > > > > > 
> > > > > >    A SIP client using an unreliable transport 
> > protocol such as UDP
> > > > > >    SHOULD retransmit requests other than INVITE or ACK [...]
> > > > > > 
> > > > > > Look to section 10.3 for reliability-related behaviour 
> > > > for INVITEs.
> > > > > > 
> > > > > > 
> > > > > >  - Jo.
> > > > > > 
> > > > > > 
> > > > > > ----- End forwarded message -----
> > > > > > 
> > > > > > _______________________________________________
> > > > > > This list is for continuing development of the SIP protocol.
> > > > > > The sip-implementer's list is the place to discuss 
> > implementation,
> > > > > > and to receive advice on understanding existing sip.
> > > > > > To subscribe to it, send mail to 
> > majordomo@cs.columbia.edu with
> > > > > > "subscribe sip-implementors" in the body.
> > > > > > 
> > > > 
> > > > _______________________________________________
> > > > This list is for continuing development of the SIP protocol.
> > > > The sip-implementer's list is the place to discuss implementation,
> > > > and to receive advice on understanding existing sip.
> > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > > "subscribe sip-implementors" in the body.
> > > > 
> > > 
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementer's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > "subscribe sip-implementors" in the body.
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> > 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 11:50:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25230
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 11:50:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7541344372; Wed, 24 Jan 2001 10:51:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 245B744336
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 10:50:28 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0OGoIO08640;
	Wed, 24 Jan 2001 10:50:18 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: sip@lists.bell-labs.com
Cc: rohan@cisco.com
Message-ID: <20010124104917.A27867@fdd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Subject: [SIP] REFER issues
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 10:49:17 -0600


Dear SIP list,

I apologize for only publishing my side of
this debate, but I feel right publishing
other people private correspondence.  I need
to publish my comments, so I don't
to endlessly repeat myself in many conversations.

--
Rick

> Rohan,
> 
> Thank you for your thoughts.  I wrote this off line last night.
>
> I agree HANDOFF is very late in comming.  Hopefully, not too
> late.  It would mean some abandoned REFER work for me as well.
> 
> I would be powerful if a remote host forwards all of its sniffed
> packets to me, and the remote sends any packet I forward to
> it.  Admittedly extreme, but not only would it ignore security and
> privacy, it has implemented nothing.  The work has simply
> been moved around.
> 
> Without a layered architecture, I don't know how to assign
> the functionality of HANDOFF and PhoneControl to different
> programmers using REFER.  If we can cleanly separate these
> two, should we?
> 
> The syntax of REFER is more complicated.  Do you know when to escape?
> How about REFER with a method=refer?  The readability of
> SIP is lost.
> 
> What kinds of security precautions should I put in my
> REFER implementation?   If there is a level less than root,
> what should it do with headers it doesn't recognize?
> How many pages is your sandbox design?  ...and megabytes of
> code?  .... or bug reports?
> 
> If I already implement PhoneControl to talk to a PDA or
> PC helper app, should I also support a REFER duplicate?
> ...or should the PDA and PC have a full SIP parser
> and their developers be SIP experts?
> 
> If we remove HANDOFF, PhoneControl, and JOIN functionality
> from REFER,  what is left?   (Hopefully nobody ever drafts JOIN.)
> 
> --
> Rick
> 
> BTW, the join wording of PHONECTL was changed to handoff.  Some
> typos were fixed.   http://phonectl.sfour.com/
 
 
 
> Rohan,
> 
> Agreed that TAKE is another primitive supported
> by REFER, but not covered in the other drafts.
> I reject REFER in part because I don't want TAKE.
> 
> Without PHONECTL access, how do I know about the
> call leg I am going to take?  Do you expect a
> subscription to allow me to see all of someone
> else's SIP traffic?   Heck, with that why not forge
> BYE and HANDOFF messages in the call-leg?
> 
> Will your UA handoff a call to another with
> the expectation of being able to take it back?
> What if the remote entity doesn't cooperate?
> You won't learn until too late.  The error
> message would be comical.  With my envisioned
> TAKE scenarios, the participants are too
> altruistic.
> 
> Taking back a call from a music-on-hold server
> would be slower than ending a B2BUA.  Please don't
> assume every network device is within a 20ms ping time.
> I like to count by 100ms, and this doesn't assume loss.
> 
> We are working on a draft for pickup.  The current
> designs require a centralized privledged server.
> I don't totally like them.  Maybe a TAKE
> method would be good for this for rining calls only.
> Nonetheless, the action of reviewing ringing
> calls and instructing one to transfer is better
> suited by a remote control layer, e.g. phonectl.
> 
> To support phone provisioned pickup privledges, wouldn't
> you need to modify some user interface.  At this
> time wouldn't the SIP be modified to support it?
> I don't buy your arguement against needing to code
> additional methods being a problem.
> 
> Thank you for hearing me out.
> 
> --
> Rick
> 
 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 12:33:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26106
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 12:33:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2644C4436F; Wed, 24 Jan 2001 11:34:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id CD59244336
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 11:33:52 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0OHXgx07461;
	Wed, 24 Jan 2001 11:33:42 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: Bryan Byerly <byerly@cisco.com>
Cc: sip@lists.bell-labs.com, aaron_madsen@3com.com
Subject: Re: [SIP] Announcements in SIP (401 & 407 contact)
Message-ID: <20010124113337.A20292@fdd.com>
References: <3A6C65A1.2E25E09C@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A6C65A1.2E25E09C@cisco.com>; from byerly@cisco.com on Mon, Jan 22, 2001 at 11:53:54AM -0500
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 11:33:37 -0600


Sadly, I just discovered the hard way that the contact
header of a 407 and 401 (authentication required) response
is like 3xx not 200.  

From: draft-ietf-sip-rfc2543bis-02.txt
>        4xx, 5xx and 6xx responses: The Contact response-header field
>             can be used with a 4xx, 5xx or 6xx response to indicate the
>             location where additional information about the error can
>             be found.

I suppose this also means these response cannot form a route.

Does anyone use them in this fashon for 401 and 407?  

--
Rick


On Mon, Jan 22, 2001 at 11:53:54AM -0500, Bryan Byerly wrote:
> Hi guys,
> 
> I'd like to solicit ideas/consensus w/r/t announcements in SIP.
> 
> For this thread of discussion, we're talking about announcements which
> are played when an error occurred during call setup.  For instance, on
> 404, a message could be played "The URL you have dialed B...O...B. is
> not in service, please check the URL or dial the operator for
> assistance".
> 
> There are at least two desired behaviors w/r/t annoucements:
> Desired behavior 1: There should be a mechanism so that local
> annoucements override network annoucements.
> Desired behavior 2: There should be a mechanism so that announcements
> are not billable.
> 
> Like call forwarding features in SIP, there are implementable solutions
> to play annoucements using user agents or proxies.
> 
> In the diagrams below, A, B, and C are user agents, Po is an originating
> proxy and Pt is a terminating proxy.
> 
> User agent: Event based local announcement
> A                 Po             Pt
> |                  |              |
> |--INV Bob@B------>|              |
> |                  |              |
> |<-404-------------|              |
> |                  |              |
> A generates
> local audio
> indicating
> "The URL you have dialed B...O...B is not in service, please check the
>  URL or dial the operator for assistance."
> 
> 
> Proxy: Event based call diversion (recursive)
> A                  Po             Pt        Announcement
>                                               Server
> |                  |              |             |
> |--INV Bob@B------>|              |             |
> |                  |--INV Bob@B-->|             |
> |                  |<-404---------|             |
> |            proxy implements     |             |
> |            call forward on 404  |             |
> |                  |--INV AnnServer------------>|
> |                  |  Diversion: Bob@B          |
> |                  |              |             |
> |<-200------------------------------------------|
> |<==="The URL you have dialed B...O...B is not==|
> |     in service, please check the URL or dial  |
> |     the operator for assistance"
> 
> 
> Both approaches are viable and there are advantages/disadvantages to
> each.  If all user agents supported local generation of announcements,
> then an event based call diversion solution may not be needed.  However,
> in today's world, many user agent implementations do not have support
> for generating local announcements.
> 
> Advantages for "event based local announcements"
> a) requires no network bandwidth
> b) requires no annoucements server
> 
> Disadvantages for "event based local announcements"
> a) Not all SIP user agents support locally generated announcements
> b) provisioning issues for large-scale deployments. (i.e. If desirable,
> how would a network admin configure multi-vendor SIP phones in his net
> with certain announcements).
> 
> Advantages for "event based call diversion"
> a) Provides annoucement support in multi-vendor networks across all SIP
> user agents
> b) Provisioning is centralized at proxy and announcement server
> 
> Disadvantages for "event based call diversion"
> a) requires network bandwidth to play annoucements
> b) requires presence of an announcements server
> 
> I'm not interested in a holy war of which to use.  Each solution will be
> appropriate for certain network deployments.  There will soon be
> implementations of event based local annoucements and event based call
> diversion.  The more important issue is to define a mechanism to get
> desired feature interaction.
> 
> 
> 
> Desired behavior 1: There should be a mechanism so that local
> annoucements override network annoucements.
> 
> I would like the behavior that locally generated annoucements take
> precendence over proxy event based call diversion.  In other words,
> given a UA that is configured to play announcement X and proxy that is
> configured to divert to an announcement server to play message Y, I want
> X to be played.  i.e. I want the behavior of a smart UA to be able to
> override the behavior (provided by proxies in the network) to dumb UAs.
> 
> Unfortunately, Po gets a chance to divert the call first:
> Proxy: Event based call diversion (recursive)
> A                  Po             Pt         AnnServer
> |                  |              |             |
> |--INV Bob@B------>|              |             |
> |                  |--INV Bob@B-->|             |
> |                  |<-404---------|             |
> |            proxy implements     |             |
> |            call forward on 404  |             |
> |                  |--INV AnnServer------------>|
> |                  |  Diversion: Bob@B          |
> |                  |              |             |
> |<-200------------------------------------------|
> |<==="The URL you have dialed B...O...B is not==|
> |     in service, please check the URL or dial  |
> |     the operator for assistance"
> 
> Solution 1a: Non-recursive implementation of call diversion
> A possible solution would be to implement the diversion non-recursively:
> 
> Proxy: Event based call diversion (non-recursive)
> A                  Po             Pt         AnnServer
> |                  |              |             |
> |--INV Bob@B------>|              |             |
> |                  |--INV Bob@B-->|             |
> |                  |<-404---------|             |
> |            proxy implements     |             |
> |            non-recursive        |             |
> |            call forward on 404  |             |
> |<-302-------------|              |             |
> |  Contact: AnnServer             |             |
> |  Diversion: Bob@B; reason=404   |             |
> |                  |              |             |
> |--INV AnnServer------------------------------->|
> |  Diversion: Bob@B; reason=404   |             |
> |                  |              |             |
> |<-200------------------------------------------|
> |<==="The URL you have dialed B...O...B is not==|
> |     in service, please check the URL or dial  |
> |     the operator for assistance"
> 
> then the feature interaction could be:
> A ignores 302s with Diversion header indicating reason codes for which A
> local generation of annoucements.
> Proxy: Event based call diversion (non-recursive)
> User agent: Event based local announcement (overriding 302s with already
> covered Diversion reason codes)
> A                  Po             Pt         AnnServer
> |                  |              |             |
> |--INV Bob@B------>|              |             |
> |                  |--INV Bob@B-->|             |
> |                  |<-404---------|             |
> |            proxy implements     |             |
> |            non-recursive        |             |
> |            call forward on 404  |             |
> |<-302-------------|              |             |
> |  Contact: AnnServer             |             |
> |  Diversion: Bob@B; reason=404   |             |
> |                  |              |             |
> A generates
> local audio
> indicating
> "The URL you have dialed B...O...B is not in service, please check the
>  URL or dial the operator for assistance."
> 
> Solution 1b: "Supported: annoucements" header
> Another possible solution would be for smart UAs (that support
> announcements) to use a "Supported: annoucements" header.  This
> supported header would be used to indicate to proxies that they should
> not implement event based call forwarding (for annoucements):
> 
> Proxy: Event based call diversion (deferring implementation to UAC when
> "Supported: annoucements" is present)
> User agent: Event based local announcement
> A                 Po             Pt
> |                  |              |
> |--INV Bob@B------>|              |
> |  Supported: annoucements        |
> |                  |              |
> |<-404-------------|              |
> |                  |              |
> A generates
> local audio
> indicating
> "The URL you have dialed B...O...B is not in service, please check the
>  URL or dial the operator for assistance."
> 
> 
> 
> Desired behavior 2:  There should be a mechanism so that announcements
> are not billable.
> 
> Another issue that has been raised w/r/t annoucements in networks where
> SIP signalling is billable.  The concern is that in SIP networks where
> 200 is used to write a start record, implementation of proxy event based
> call diversion might generate a charge.
> 
> Solution 2a: Play annoucements as early media
> One solution that has been proposed is to play annoucements as early
> media:
> 
> For example, recursively:
> A                  Po             Pt         AnnServer
> |                  |              |             |
> |--INV Bob@B------>|              |             |
> |                  |--INV Bob@B-->|             |
> |                  |<-404---------|             |
> |            proxy implements     |             |
> |            call forward on 404  |             |
> |                  |--INV AnnServer------------>|
> |                  |  Diversion: Bob@B          |
> |                  |              |             |
> |<-183------------------------------------------|
> |  Content-Disposition: session                 |
> |<==="The URL you have dialed B...O...B is not==|
> |     in service, please check the URL or dial  |
> |     the operator for assistance"
> |<-CANCEL---------------------------------------|
> |--200 (CANCEL)-------------------------------->|
> 
> or non-recursively:
> A                  Po             Pt         AnnServer
> |                  |              |             |
> |--INV Bob@B------>|              |             |
> |                  |--INV Bob@B-->|             |
> |                  |<-404---------|             |
> |            proxy implements     |             |
> |            non-recursive        |             |
> |            call forward on 404  |             |
> |<-302-------------|              |             |
> |  Contact: AnnServer             |             |
> |  Diversion: Bob@B; reason=404   |             |
> |                  |              |             |
> |--INV AnnServer------------------------------->|
> |  Diversion: Bob@B; reason=404   |             |
> |                  |              |             |
> |<-183------------------------------------------|
> |  Content-Disposition: session                 |
> |<==="The URL you have dialed B...O...B is not==|
> |     in service, please check the URL or dial  |
> |     the operator for assistance"
> |<-CANCEL---------------------------------------|
> |--200 (CANCEL)-------------------------------->|
> 
> Solution 2b: Backend billing system is aware of (non-billable)
> Announcement Server URL
> Another possible solution is that the URL of the AnnServer could be
> well-known to the backend billing system and that any accounting records
> written connection to the AnnServer would not be billed.
> 
> I'd like to solicit others' ideas, problems, and proposed solutions
> w/r/t annoucements in SIP.
> 
> I'm also looking for co-authors to write an I-D w/r/t announcements.  If
> interested, please contact me directly at byerly@cisco.com.
> 
> thanks for your help,
> Bryan
> 
> Bryan J. Byerly
> byerly@cisco.com
> 
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 13:05:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26722
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 13:05:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 900BE4433D; Wed, 24 Jan 2001 12:06:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id E033344336
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 12:05:58 -0500 (EST)
Received: (qmail 8515 invoked by uid 500); 24 Jan 2001 18:11:12 -0000
From: David Frascone <dave@frascone.com>
To: sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
Message-ID: <20010124121112.M7103@newman.frascone.com>
Mail-Followup-To: sip@lists.bell-labs.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 12:11:12 -0600

This bounced when Pat tried to send it, so I'm forwarding it.  

----- Forwarded message from Pat Calhoun <pcalhoun@eng.sun.com> -----

Date: Wed, 24 Jan 2001 09:15:44 -0800 (PST)
From: Pat Calhoun <pcalhoun@eng.sun.com>
Reply-To: Pat Calhoun <pcalhoun@eng.sun.com>
Subject: Re: [SIP] T2 and 182 Queued
To: David Frascone <dave@frascone.com>
Cc: sip@lists.bell-labs.com
Message-ID: <Roam.SIMC.2.0.6.980356544.32567.pcalhoun@nasnfs>

> 
> Everything is happy above.  But, what about this:
> 
> 
>     UA1                             UA2
>      |                               |
>      |             INVITE            |
>      |------------------------------>|
>      |                               |
>      |      182 Queue Position 120   |
>      |<------------------------------|
>      |                               |
>    Here, the UA1 pulls the plug on his computer, drives into a tunnel,
>    has a power outage, ISP drops the connection, etc.  No cancel, just
>    vanishes.
> 
>      |      182 Queue Position 110   |
>      |<------------------------------|
>      |                               |
>      |      182 Queue Position 100   |
>      |<------------------------------|
>      |                               |
>      |      182 Queue Position 1     |
>      |<------------------------------|
>      |                               |
>      |            200 OK F4          |
>      |<------------------------------|
>      |                               |
>      |   UA2 Timer FINALLY times out |
>      |                               |
>     UA1                             UA2
> 
> 
> So, the UA keeps him in the queue, spitting out UDP packets for a LONG
> time, without ever knowing that UA1 is no longer on the network.  So, if
> T2 *is* used, the timeout is way too short.  If T2 is NOT used, then there
> is an big waste of retransmissions for queued calls.  Perhaps PRACK should be
> required for long queue times?  There might even be a DOS attack by forging
> tons of INVITES to a full queue.
> 
> Now do you see the problem?  

Putting aside the obvious case of wasted resources, I think that the potential
for denial of service attacks is THE reason why this is broken. Imagine
competitor A issuing a UDP based IP address spoofing attack on competitor B,
filling up their call queues. With the number of calls, the queue will quickly
fill up, so I believe it is a MUST that the 182 messages be ack'ed, to reduce
the queue size. This should be a MUST, regardless of the wait time.

I think that proofing against DoS attacks should be a high priority item for
the WG.

PatC


----- End forwarded message -----

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 13:21:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27086
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 13:21:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C051C443A2; Wed, 24 Jan 2001 12:22:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from calum.csclub.uwaterloo.ca (calum.csclub.uwaterloo.ca [129.97.134.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 0908044387
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 12:21:11 -0500 (EST)
Received: (from wbiggs@localhost)
	by calum.csclub.uwaterloo.ca (8.9.3+Sun/8.9.3) id NAA16237;
	Wed, 24 Jan 2001 13:26:13 -0500 (EST)
From: Billy Biggs <billy@billybiggs.com>
To: David Frascone <dave@frascone.com>
Cc: Pat Calhoun <pcalhoun@eng.sun.com>, Sip List <sip@lists.bell-labs.com>
Subject: Re: [SIP] T2 and 182 Queued
Message-ID: <20010124132611.A16087@csclub.uwaterloo.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 13:26:13 -0500

> > Everything is happy above.  But, what about this:
> > 
> > 
> >     UA1                             UA2
> >      |                               |
> >      |             INVITE            |
> >      |------------------------------>|
> >      |                               |
> >      |      182 Queue Position 120   |
> >      |<------------------------------|
> >      |                               |
> >
> >    Here, the UA1 pulls the plug on his computer, drives into a
> >    tunnel, has a power outage, ISP drops the connection, etc.  No
> >    cancel, just vanishes.
> > 
> >      |      182 Queue Position 110   |
> >      |<------------------------------|
> >      |                               |
> >      |      182 Queue Position 100   |
> >      |<------------------------------|
> >      |                               |
> >      |      182 Queue Position 1     |
> >      |<------------------------------|
> >      |                               |
> >      |            200 OK F4          |
> >      |<------------------------------|
> >      |                               |
> >      |   UA2 Timer FINALLY times out |
> >      |                               |
> >     UA1                             UA2
> > 
> > So, the UA keeps him in the queue, spitting out UDP packets for a
> > LONG time, without ever knowing that UA1 is no longer on the
> > network.  So, if T2 *is* used, the timeout is way too short.  If T2
> > is NOT used, then there is an big waste of retransmissions for
> > queued calls.  Perhaps PRACK should be required for long queue
> > times?  There might even be a DOS attack by forging tons of INVITES
> > to a full queue.
> > 
> > Now do you see the problem?  
> 
> Putting aside the obvious case of wasted resources, I think that the
> potential for denial of service attacks is THE reason why this is
> broken. Imagine competitor A issuing a UDP based IP address spoofing
> attack on competitor B, filling up their call queues. With the number
> of calls, the queue will quickly fill up, so I believe it is a MUST
> that the 182 messages be ack'ed, to reduce the queue size. This should
> be a MUST, regardless of the wait time.

  There are more reasons why 182 Queued is a bad implementation:

  1. PSTN Gateways will have a difficult time doing text-to-speach on
     the reason phrase to play to PSTN callers, and I bet most will just
     play ringing.

  2. Proxies in the middle may decide they don't want to keep state past
     a minute or so, and will CANCEL the call themselves, returning 408
     Timeout or something.

  Any reasonable implementation of queuing will just connect the call
and inform the caller in the audio band to avoid problems.  To save
network bandwidth, the queueing system will just put the remote end on
hold appropriately.  This lets the system happily ping the far end.

  I doubt many people will actually use 182 in practice.  That said, it
does look good on paper, and I don't think it's worth removing from the
spec.

-- 
Billy Biggs
wbiggs@csclub.uwaterloo.ca

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 13:28:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27196
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 13:28:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 40C7B443AE; Wed, 24 Jan 2001 12:29:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196])
	by lists.bell-labs.com (Postfix) with ESMTP id 16CA5443AD
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 12:28:34 -0500 (EST)
Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174])
	by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id MAA23360;
	Wed, 24 Jan 2001 12:30:13 -0600
Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0)
	id <YB5MTX7Y>; Wed, 24 Jan 2001 12:26:29 -0600
Message-ID: <DBD1CC7CE357D211AECC009027158FD103BFE28B@itmail-ict1-imc.wichita.brite.com>
From: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com>
To: David Frascone <dave@frascone.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] T2 and 182 Queued
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 12:26:28 -0600

Hi David,

If I understand your issue correctly, you are concerned with 
how long UA2 waits before it gives up on UA1 after sending 
200 OK.  Section 10.5.1 addresses this case, in it final 
responses are sent a total of 7 times with retransmission 
timer starting at T1 and doubling each time.  I understand 
this to mean UA2 waits 28 seconds (plus a little to see if 
the last retransmission gets acknowledged) for the ACK from 
UA1.  If not received, UA2 tears down the call.  Using your 
example, the customer support rep. will wait 28 seconds 
before moving on to the next call.  Not that bad but 28 
seconds of the support rep's time has been non-productive. 
this might encourage the organization to shorten the queue. 
The frequency at which the 182s are sent by UA2 is up to 
UA2.  200 OK is the only message retransmitted.  No big 
waste of transmissions that I see.

I hope this helps,
Bert

> -----Original Message-----
> From: David Frascone [mailto:dave@frascone.com]
> Sent: Wednesday, January 24, 2001 11:43 AM
> To: sip@lists.bell-labs.com
> Subject: Re: [SIP] T2 and 182 Queued
> 
> 
> Ok, but let me get this straight.  This call flow looks like 
> it is broken
> with the current RFC.  Let me know if I am wrong.  It seems 
> broken even
> without a proxy.  In the following, I'm assuming a 20-30 
> minute queue wait.
> Not unreasonable if you've ever called customer support about 
> a DSL line :)
> 
> Ok, Here is a good call:
> 
>     UA1                             UA2
>      |                               |
>      |             INVITE            |
>      |------------------------------>|
>      |                               |
>      |      182 Queue Position 20    |
>      |<------------------------------|
>      |                               |
>      |      182 Queue Position 10    |
>      |<------------------------------|
>      |                               |
>      |      182 Queue Position 1     |
>      |<------------------------------|
>      |                               |
>      |            200 OK F4          |
>      |<------------------------------|
>      |                               |
>      |               ACK             |
>      |------------------------------>|
>      |                               |
>     UA1                             UA2
> 
> Everything is happy above.  But, what about this:
> 
> 
>     UA1                             UA2
>      |                               |
>      |             INVITE            |
>      |------------------------------>|
>      |                               |
>      |      182 Queue Position 120   |
>      |<------------------------------|
>      |                               |
>    Here, the UA1 pulls the plug on his computer, drives into a tunnel,
>    has a power outage, ISP drops the connection, etc.  No cancel, just
>    vanishes.
> 
>      |      182 Queue Position 110   |
>      |<------------------------------|
>      |                               |
>      |      182 Queue Position 100   |
>      |<------------------------------|
>      |                               |
>      |      182 Queue Position 1     |
>      |<------------------------------|
>      |                               |
>      |            200 OK F4          |
>      |<------------------------------|
>      |                               |
>      |   UA2 Timer FINALLY times out |
>      |                               |
>     UA1                             UA2
> 
> 
> So, the UA keeps him in the queue, spitting out UDP packets for a LONG
> time, without ever knowing that UA1 is no longer on the 
> network.  So, if
> T2 *is* used, the timeout is way too short.  If T2 is NOT 
> used, then there
> is an big waste of retransmissions for queued calls.  Perhaps 
> PRACK should be
> required for long queue times?  There might even be a DOS 
> attack by forging
> tons of INVITES to a full queue.
> 
> Now do you see the problem?  
> 
> 
> 
> On Wed, Jan 24, 2001 at 11:35:47AM +0200, Itamar Gilad wrote:
> > David,
> > 
> 
> 
> On Wed, Jan 24, 2001 at 11:35:47AM +0200, Itamar Gilad wrote:
> > David,
> > 
> > we found that on top of T1 and T2 there's a need for 
> "transaction timeouts"
> > i.e. a timer that terminates the transaction simply because nothing
> > significant happened for a given period of time. Note that 
> the durations of
> > these timeouts vary based on the current state of the 
> transaction. Without
> > these timeouts some transactions might never die. You can find some
> > references to this matter in RFC 2543-bis02. 
> > 
> >   Itamar 
> > 
> > > -----Original Message-----
> > > From: David Frascone [mailto:dave@frascone.com]
> > > Sent: Tue, January 23, 2001 9:44 PM
> > > To: sip@lists.bell-labs.com
> > > Subject: Re: [SIP] T2 and 182 Queued
> > > 
> > > 
> > > So, a proxy server would just retransmit the 182 
> > > indefinately?  I thought the
> > > proxy retransmission timer was also tied to T2.
> > > 
> > > Hehe, maybe I should just use TCP :)
> > > 
> > > On Tue, Jan 23, 2001 at 02:17:49PM -0500, Eric Tremblay wrote:
> > > > David,
> > > > 
> > > > 10.3.1 states that INVITES are retransmitted after T1 
> > > seconds, and this
> > > > value doubles after each retransmission.  Retransmissions 
> > > are stopped when
> > > > receiving any kind of response (provisional or definitive). 
> > >  As soon as a
> > > > UAC receives a 182, it simply stops retransmitting its 
> > > INVITE and waits for
> > > > a final response (which can take a lot of time to come).
> > > > 
> > > > EricT
> > > > 
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: David Frascone [mailto:dave@frascone.com]
> > > > > Sent: Monday, January 22, 2001 12:47
> > > > > To: sip@lists.bell-labs.com
> > > > > Subject: Re: [SIP] T2 and 182 Queued
> > > > > 
> > > > > 
> > > > > You are right.  I did copy the wrong paragraph.  But, I still 
> > > > > can't find 
> > > > > anywhere in 10.3 that stops the T2 timer.  It says that 
> > > > > provisional responses
> > > > > are re-sent upon every duplicate request, but it never resets 
> > > > > the T2 timer.
> > > > > 
> > > > > My concern is not retransmissions, but the total call setup 
> > > > > time, which 
> > > > > could take much longer than T2 allows, if the call is queued.
> > > > > 
> > > > > Now, if the timers are just a suggestion, and the user agent 
> > > > > can do whatever
> > > > > it wants, then this is not a problem.  I know that I can set 
> > > > > T1 and T2 to
> > > > > whatever values I want, but I'd prefer to have a queued call 
> > > > > work within
> > > > > the "suggested" parameters of 500ms and 4sec as set 
> by the RFC.
> > > > > 
> > > > > Comments?  Does anyone really care?  Should I ignore this, 
> > > > > and just set my
> > > > > T2 timer really high?
> > > > > 
> > > > > 
> > > > > 
> > > > > On Mon, Jan 22, 2001 at 05:29:45PM -0000, Jo Hornsby wrote:
> > > > > > David Frascone wrote:
> > > > > > > Given this forwarded discussion, this might be an 
> > > error in 02bis.
> > > > > > 
> > > > > > It might be.  But given the fact that section 10.2 
> is entitled:
> > > > > > "Reliability for Requests Other Than INVITE", I suspect it 
> > > > > is not. &:)
> > > > > > 
> > > > > > > ----- Forwarded message from Jo Hornsby 
> > > > > <jhornsby@ubiquity.net> -----
> > > > > > > 
> > > > > > > From: "Jo Hornsby" <jhornsby@ubiquity.net>
> > > > > > > To: "David Frascone" <dave@frascone.com>, 
> > > > > > > <sip-implementors@cs.columbia.edu>
> > > > > > > Subject: RE: [SIP] T2 and 182 Queued
> > > > > > > Date: Mon, 22 Jan 2001 15:47:36 -0000
> > > > > > > Message-ID: 
> <000001c0848a$a4281f20$4e34c3c1@ubiquity.co.uk>
> > > > > > > 
> > > > > > > David Frascone wrote:
> > > > > > > >
> > > > > > > > Does anyone know the answer to this?  Should I switch 
> > > > > to the sip list?
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Jan 19, 2001 at 11:16:13AM -0600, David 
> > > Frascone wrote:
> > > > > > > > > From section 10.2.1:
> > > > > > > > >
> > > > > > > > >    Subsequent retransmissions are spaced by T2 
> > > > > seconds. If the client
> > > > > > > > >    receives a provisional response, it continues to 
> > > > > retransmit the
> > > > > > > > >    request, but with an interval of T2 seconds. 
> > > > > Retransmissions cease
> > > > > > > > >    when the client has sent a total of eleven 
> > > > > packets, or receives a
> > > > > > > > >    definitive response. Default values for T1 and 
> > > T2 are 500 
> > > > > > > ms and 4 s,
> > > > > > > > >    respectively. Clients MAY use larger values, but 
> > > > > SHOULDNOT use
> > > > > > > > >    smaller ones. Servers retransmit the response upon 
> > > > > receipt of a
> > > > > > > > >
> > > > > > > > > Which means, the INVITE would be retransmitted 
> > > every 4 seconds
> > > > > > > > > while the caller is waiting in the queue.  And, would 
> > > > > stop after
> > > > > > > > > 11 retransmissions, or 44 seconds, which is still too 
> > > > > small for
> > > > > > > > > some queues.
> > > > > > > 
> > > > > > > You are correct -- the text you quoted does say this. 
> > >  However,
> > > > > > > if you seek to the beginning of the same 
> paragraph, you find:
> > > > > > > 
> > > > > > >    A SIP client using an unreliable transport 
> > > protocol such as UDP
> > > > > > >    SHOULD retransmit requests other than INVITE 
> or ACK [...]
> > > > > > > 
> > > > > > > Look to section 10.3 for reliability-related behaviour 
> > > > > for INVITEs.
> > > > > > > 
> > > > > > > 
> > > > > > >  - Jo.
> > > > > > > 
> > > > > > > 
> > > > > > > ----- End forwarded message -----
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > This list is for continuing development of the 
> SIP protocol.
> > > > > > > The sip-implementer's list is the place to discuss 
> > > implementation,
> > > > > > > and to receive advice on understanding existing sip.
> > > > > > > To subscribe to it, send mail to 
> > > majordomo@cs.columbia.edu with
> > > > > > > "subscribe sip-implementors" in the body.
> > > > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > This list is for continuing development of the SIP protocol.
> > > > > The sip-implementer's list is the place to discuss 
> implementation,
> > > > > and to receive advice on understanding existing sip.
> > > > > To subscribe to it, send mail to 
> majordomo@cs.columbia.edu with
> > > > > "subscribe sip-implementors" in the body.
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > This list is for continuing development of the SIP protocol.
> > > > The sip-implementer's list is the place to discuss 
> implementation,
> > > > and to receive advice on understanding existing sip.
> > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > > "subscribe sip-implementors" in the body.
> > > 
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementer's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > "subscribe sip-implementors" in the body.
> > > 
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 13:41:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27598
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 13:41:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6C826443A0; Wed, 24 Jan 2001 12:42:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id BB92644398
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 12:41:11 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA19618;
	Wed, 24 Jan 2001 13:40:51 -0500 (EST)
Message-ID: <3A6F21B3.F9BC9612@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com>,
        sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
References: <DBD1CC7CE357D211AECC009027158FD103BFE28B@itmail-ict1-imc.wichita.brite.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 13:40:51 -0500
Content-Transfer-Encoding: 7bit

182 can be sent for days, if desired, without any connection to T2. How
long this is done is up to the sender of the 182, obviously (and any
intervening proxies). But the proxy will likely be in the called
organization, so as long as the proxy plays along, proxy timeout is not
an issue.

A somewhat related question is whether it makes sense to extend the
session timer mechanism to this case. I haven't thought through all the
consequences (depending on how CSeq is handled, this is either an
overlapping transaction or not), but it would allow consenting parties
to prevent this and still signal in the appropriate way (i.e., without
audio).

I suspect that in many cases, SUBSCRIBE/NOTIFY may be the more
appropriate mechanism for ACD-like systems in the future.

Dumb PSTN gateways are never an excuse for falling back to silly audio
signaling, with all its attendant problems.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 13:52:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27868
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 13:52:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 65A1944387; Wed, 24 Jan 2001 12:53:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id E1FC444336
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 12:52:19 -0500 (EST)
Received: (qmail 9071 invoked by uid 500); 24 Jan 2001 18:57:34 -0000
From: David Frascone <dave@frascone.com>
To: sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
Message-ID: <20010124125734.C7103@newman.frascone.com>
Mail-Followup-To: sip@lists.bell-labs.com
References: <DBD1CC7CE357D211AECC009027158FD103BFE28B@itmail-ict1-imc.wichita.brite.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <DBD1CC7CE357D211AECC009027158FD103BFE28B@itmail-ict1-imc.wichita.brite.com>; from bert.culpepper@intervoice-brite.com on Wed, Jan 24, 2001 at 12:26:28PM -0600
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 12:57:34 -0600

It started with a couple of things:

First: If a caller is queued, and a UA uses the timers, then he can
only be on hold for 28 secs, as you mentioned.  This is WAY shorter
than most queue times.

Second: If you ignore the timers, then the caller can be on hold 
indeffinitely, even if he is no longer even on the 'net.  (Assuming
UDP transport, of course)

-Dave

On Wed, Jan 24, 2001 at 12:26:28PM -0600, Culpepper, Bert wrote:
> Hi David,
> 
> If I understand your issue correctly, you are concerned with 
> how long UA2 waits before it gives up on UA1 after sending 
> 200 OK.  Section 10.5.1 addresses this case, in it final 
> responses are sent a total of 7 times with retransmission 
> timer starting at T1 and doubling each time.  I understand 
> this to mean UA2 waits 28 seconds (plus a little to see if 
> the last retransmission gets acknowledged) for the ACK from 
> UA1.  If not received, UA2 tears down the call.  Using your 
> example, the customer support rep. will wait 28 seconds 
> before moving on to the next call.  Not that bad but 28 
> seconds of the support rep's time has been non-productive. 
> this might encourage the organization to shorten the queue. 
> The frequency at which the 182s are sent by UA2 is up to 
> UA2.  200 OK is the only message retransmitted.  No big 
> waste of transmissions that I see.
> 
> I hope this helps,
> Bert
> 
> > -----Original Message-----
> > From: David Frascone [mailto:dave@frascone.com]
> > Sent: Wednesday, January 24, 2001 11:43 AM
> > To: sip@lists.bell-labs.com
> > Subject: Re: [SIP] T2 and 182 Queued
> > 
> > 
> > Ok, but let me get this straight.  This call flow looks like 
> > it is broken
> > with the current RFC.  Let me know if I am wrong.  It seems 
> > broken even
> > without a proxy.  In the following, I'm assuming a 20-30 
> > minute queue wait.
> > Not unreasonable if you've ever called customer support about 
> > a DSL line :)
> > 
> > Ok, Here is a good call:
> > 
> >     UA1                             UA2
> >      |                               |
> >      |             INVITE            |
> >      |------------------------------>|
> >      |                               |
> >      |      182 Queue Position 20    |
> >      |<------------------------------|
> >      |                               |
> >      |      182 Queue Position 10    |
> >      |<------------------------------|
> >      |                               |
> >      |      182 Queue Position 1     |
> >      |<------------------------------|
> >      |                               |
> >      |            200 OK F4          |
> >      |<------------------------------|
> >      |                               |
> >      |               ACK             |
> >      |------------------------------>|
> >      |                               |
> >     UA1                             UA2
> > 
> > Everything is happy above.  But, what about this:
> > 
> > 
> >     UA1                             UA2
> >      |                               |
> >      |             INVITE            |
> >      |------------------------------>|
> >      |                               |
> >      |      182 Queue Position 120   |
> >      |<------------------------------|
> >      |                               |
> >    Here, the UA1 pulls the plug on his computer, drives into a tunnel,
> >    has a power outage, ISP drops the connection, etc.  No cancel, just
> >    vanishes.
> > 
> >      |      182 Queue Position 110   |
> >      |<------------------------------|
> >      |                               |
> >      |      182 Queue Position 100   |
> >      |<------------------------------|
> >      |                               |
> >      |      182 Queue Position 1     |
> >      |<------------------------------|
> >      |                               |
> >      |            200 OK F4          |
> >      |<------------------------------|
> >      |                               |
> >      |   UA2 Timer FINALLY times out |
> >      |                               |
> >     UA1                             UA2
> > 
> > 
> > So, the UA keeps him in the queue, spitting out UDP packets for a LONG
> > time, without ever knowing that UA1 is no longer on the 
> > network.  So, if
> > T2 *is* used, the timeout is way too short.  If T2 is NOT 
> > used, then there
> > is an big waste of retransmissions for queued calls.  Perhaps 
> > PRACK should be
> > required for long queue times?  There might even be a DOS 
> > attack by forging
> > tons of INVITES to a full queue.
> > 
> > Now do you see the problem?  
> > 
> > 
> > 
> > On Wed, Jan 24, 2001 at 11:35:47AM +0200, Itamar Gilad wrote:
> > > David,
> > > 
> > 
> > 
> > On Wed, Jan 24, 2001 at 11:35:47AM +0200, Itamar Gilad wrote:
> > > David,
> > > 
> > > we found that on top of T1 and T2 there's a need for 
> > "transaction timeouts"
> > > i.e. a timer that terminates the transaction simply because nothing
> > > significant happened for a given period of time. Note that 
> > the durations of
> > > these timeouts vary based on the current state of the 
> > transaction. Without
> > > these timeouts some transactions might never die. You can find some
> > > references to this matter in RFC 2543-bis02. 
> > > 
> > >   Itamar 
> > > 
> > > > -----Original Message-----
> > > > From: David Frascone [mailto:dave@frascone.com]
> > > > Sent: Tue, January 23, 2001 9:44 PM
> > > > To: sip@lists.bell-labs.com
> > > > Subject: Re: [SIP] T2 and 182 Queued
> > > > 
> > > > 
> > > > So, a proxy server would just retransmit the 182 
> > > > indefinately?  I thought the
> > > > proxy retransmission timer was also tied to T2.
> > > > 
> > > > Hehe, maybe I should just use TCP :)
> > > > 
> > > > On Tue, Jan 23, 2001 at 02:17:49PM -0500, Eric Tremblay wrote:
> > > > > David,
> > > > > 
> > > > > 10.3.1 states that INVITES are retransmitted after T1 
> > > > seconds, and this
> > > > > value doubles after each retransmission.  Retransmissions 
> > > > are stopped when
> > > > > receiving any kind of response (provisional or definitive). 
> > > >  As soon as a
> > > > > UAC receives a 182, it simply stops retransmitting its 
> > > > INVITE and waits for
> > > > > a final response (which can take a lot of time to come).
> > > > > 
> > > > > EricT
> > > > > 
> > > > > 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: David Frascone [mailto:dave@frascone.com]
> > > > > > Sent: Monday, January 22, 2001 12:47
> > > > > > To: sip@lists.bell-labs.com
> > > > > > Subject: Re: [SIP] T2 and 182 Queued
> > > > > > 
> > > > > > 
> > > > > > You are right.  I did copy the wrong paragraph.  But, I still 
> > > > > > can't find 
> > > > > > anywhere in 10.3 that stops the T2 timer.  It says that 
> > > > > > provisional responses
> > > > > > are re-sent upon every duplicate request, but it never resets 
> > > > > > the T2 timer.
> > > > > > 
> > > > > > My concern is not retransmissions, but the total call setup 
> > > > > > time, which 
> > > > > > could take much longer than T2 allows, if the call is queued.
> > > > > > 
> > > > > > Now, if the timers are just a suggestion, and the user agent 
> > > > > > can do whatever
> > > > > > it wants, then this is not a problem.  I know that I can set 
> > > > > > T1 and T2 to
> > > > > > whatever values I want, but I'd prefer to have a queued call 
> > > > > > work within
> > > > > > the "suggested" parameters of 500ms and 4sec as set 
> > by the RFC.
> > > > > > 
> > > > > > Comments?  Does anyone really care?  Should I ignore this, 
> > > > > > and just set my
> > > > > > T2 timer really high?
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Mon, Jan 22, 2001 at 05:29:45PM -0000, Jo Hornsby wrote:
> > > > > > > David Frascone wrote:
> > > > > > > > Given this forwarded discussion, this might be an 
> > > > error in 02bis.
> > > > > > > 
> > > > > > > It might be.  But given the fact that section 10.2 
> > is entitled:
> > > > > > > "Reliability for Requests Other Than INVITE", I suspect it 
> > > > > > is not. &:)
> > > > > > > 
> > > > > > > > ----- Forwarded message from Jo Hornsby 
> > > > > > <jhornsby@ubiquity.net> -----
> > > > > > > > 
> > > > > > > > From: "Jo Hornsby" <jhornsby@ubiquity.net>
> > > > > > > > To: "David Frascone" <dave@frascone.com>, 
> > > > > > > > <sip-implementors@cs.columbia.edu>
> > > > > > > > Subject: RE: [SIP] T2 and 182 Queued
> > > > > > > > Date: Mon, 22 Jan 2001 15:47:36 -0000
> > > > > > > > Message-ID: 
> > <000001c0848a$a4281f20$4e34c3c1@ubiquity.co.uk>
> > > > > > > > 
> > > > > > > > David Frascone wrote:
> > > > > > > > >
> > > > > > > > > Does anyone know the answer to this?  Should I switch 
> > > > > > to the sip list?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Jan 19, 2001 at 11:16:13AM -0600, David 
> > > > Frascone wrote:
> > > > > > > > > > From section 10.2.1:
> > > > > > > > > >
> > > > > > > > > >    Subsequent retransmissions are spaced by T2 
> > > > > > seconds. If the client
> > > > > > > > > >    receives a provisional response, it continues to 
> > > > > > retransmit the
> > > > > > > > > >    request, but with an interval of T2 seconds. 
> > > > > > Retransmissions cease
> > > > > > > > > >    when the client has sent a total of eleven 
> > > > > > packets, or receives a
> > > > > > > > > >    definitive response. Default values for T1 and 
> > > > T2 are 500 
> > > > > > > > ms and 4 s,
> > > > > > > > > >    respectively. Clients MAY use larger values, but 
> > > > > > SHOULDNOT use
> > > > > > > > > >    smaller ones. Servers retransmit the response upon 
> > > > > > receipt of a
> > > > > > > > > >
> > > > > > > > > > Which means, the INVITE would be retransmitted 
> > > > every 4 seconds
> > > > > > > > > > while the caller is waiting in the queue.  And, would 
> > > > > > stop after
> > > > > > > > > > 11 retransmissions, or 44 seconds, which is still too 
> > > > > > small for
> > > > > > > > > > some queues.
> > > > > > > > 
> > > > > > > > You are correct -- the text you quoted does say this. 
> > > >  However,
> > > > > > > > if you seek to the beginning of the same 
> > paragraph, you find:
> > > > > > > > 
> > > > > > > >    A SIP client using an unreliable transport 
> > > > protocol such as UDP
> > > > > > > >    SHOULD retransmit requests other than INVITE 
> > or ACK [...]
> > > > > > > > 
> > > > > > > > Look to section 10.3 for reliability-related behaviour 
> > > > > > for INVITEs.
> > > > > > > > 
> > > > > > > > 
> > > > > > > >  - Jo.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ----- End forwarded message -----
> > > > > > > > 
> > > > > > > > _______________________________________________
> > > > > > > > This list is for continuing development of the 
> > SIP protocol.
> > > > > > > > The sip-implementer's list is the place to discuss 
> > > > implementation,
> > > > > > > > and to receive advice on understanding existing sip.
> > > > > > > > To subscribe to it, send mail to 
> > > > majordomo@cs.columbia.edu with
> > > > > > > > "subscribe sip-implementors" in the body.
> > > > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > This list is for continuing development of the SIP protocol.
> > > > > > The sip-implementer's list is the place to discuss 
> > implementation,
> > > > > > and to receive advice on understanding existing sip.
> > > > > > To subscribe to it, send mail to 
> > majordomo@cs.columbia.edu with
> > > > > > "subscribe sip-implementors" in the body.
> > > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > This list is for continuing development of the SIP protocol.
> > > > > The sip-implementer's list is the place to discuss 
> > implementation,
> > > > > and to receive advice on understanding existing sip.
> > > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > > > "subscribe sip-implementors" in the body.
> > > > 
> > > > _______________________________________________
> > > > This list is for continuing development of the SIP protocol.
> > > > The sip-implementer's list is the place to discuss implementation,
> > > > and to receive advice on understanding existing sip.
> > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > > "subscribe sip-implementors" in the body.
> > > > 
> > > 
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementer's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > "subscribe sip-implementors" in the body.
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> > 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 13:55:45 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27918
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 13:55:45 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7D9D3443BA; Wed, 24 Jan 2001 12:54:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id C6FA5443B9
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 12:53:24 -0500 (EST)
Received: (qmail 9089 invoked by uid 500); 24 Jan 2001 18:58:40 -0000
From: David Frascone <dave@frascone.com>
To: sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
Message-ID: <20010124125839.D7103@newman.frascone.com>
Mail-Followup-To: sip@lists.bell-labs.com
References: <DBD1CC7CE357D211AECC009027158FD103BFE28B@itmail-ict1-imc.wichita.brite.com> <3A6F21B3.F9BC9612@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A6F21B3.F9BC9612@cs.columbia.edu>; from hgs@cs.columbia.edu on Wed, Jan 24, 2001 at 01:40:51PM -0500
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 12:58:39 -0600

Hmmm, I hadn't considered session timers.  I was leaning more towards
manditory PRACK's.

On Wed, Jan 24, 2001 at 01:40:51PM -0500, Henning G. Schulzrinne wrote:
> 182 can be sent for days, if desired, without any connection to T2. How
> long this is done is up to the sender of the 182, obviously (and any
> intervening proxies). But the proxy will likely be in the called
> organization, so as long as the proxy plays along, proxy timeout is not
> an issue.
> 
> A somewhat related question is whether it makes sense to extend the
> session timer mechanism to this case. I haven't thought through all the
> consequences (depending on how CSeq is handled, this is either an
> overlapping transaction or not), but it would allow consenting parties
> to prevent this and still signal in the appropriate way (i.e., without
> audio).
> 
> I suspect that in many cases, SUBSCRIBE/NOTIFY may be the more
> appropriate mechanism for ACD-like systems in the future.
> 
> Dumb PSTN gateways are never an excuse for falling back to silly audio
> signaling, with all its attendant problems.
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 14:45:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28767
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 14:45:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 036E944393; Wed, 24 Jan 2001 13:46:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 1A63E44336
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 13:45:52 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0OJjh031929
	for sip@lists.bell-labs.com; Wed, 24 Jan 2001 13:45:43 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
Message-ID: <20010124134526.A439@fdd.com>
References: <DBD1CC7CE357D211AECC009027158FD103BFE28B@itmail-ict1-imc.wichita.brite.com> <20010124125734.C7103@newman.frascone.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010124125734.C7103@newman.frascone.com>; from dave@frascone.com on Wed, Jan 24, 2001 at 12:57:34PM -0600
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 13:45:26 -0600


An algorithm I am familiar with and is allowable
by the standard, is the UAC retransmits
an INVITE (same cSeq) ~30 seconds after a 
provisional response is received to see if the 
far end is still alive.  Because non-response to 
a single INVITE is not conclusive,  the UAC
restarts the 0.5, 1, 2, 4, 4,... sequence at
this time.  If no response after N INVITES
(where N <= 7 allowable in the spec) plus some
time for the far end to do a sequence, the 
call is considered dead.  This algorithm allows 
the UAC to decide how frequently he wants to 
check on the far end.  In the normal case
each check costs two packets.

Any clever ACD queueing system will probably
want to send 200 OK instead to take control
from a possible forking proxy, and to give
the user choices "press 1 to leave a voicemail".  
Nevermind that it already has to implement an audible 
progress alternative for the PSTN gateways.  I
doubt 182 will get much use.

--
Rick

On Wed, Jan 24, 2001 at 12:57:34PM -0600, David Frascone wrote:
> It started with a couple of things:
> 
> First: If a caller is queued, and a UA uses the timers, then he can
> only be on hold for 28 secs, as you mentioned.  This is WAY shorter
> than most queue times.
> 
> Second: If you ignore the timers, then the caller can be on hold 
> indeffinitely, even if he is no longer even on the 'net.  (Assuming
> UDP transport, of course)
> 
> -Dave
> 
> On Wed, Jan 24, 2001 at 12:26:28PM -0600, Culpepper, Bert wrote:
> > Hi David,
> > 
> > If I understand your issue correctly, you are concerned with 
> > how long UA2 waits before it gives up on UA1 after sending 
> > 200 OK.  Section 10.5.1 addresses this case, in it final 
> > responses are sent a total of 7 times with retransmission 
> > timer starting at T1 and doubling each time.  I understand 
> > this to mean UA2 waits 28 seconds (plus a little to see if 
> > the last retransmission gets acknowledged) for the ACK from 
> > UA1.  If not received, UA2 tears down the call.  Using your 
> > example, the customer support rep. will wait 28 seconds 
> > before moving on to the next call.  Not that bad but 28 
> > seconds of the support rep's time has been non-productive. 
> > this might encourage the organization to shorten the queue. 
> > The frequency at which the 182s are sent by UA2 is up to 
> > UA2.  200 OK is the only message retransmitted.  No big 
> > waste of transmissions that I see.
> > 
> > I hope this helps,
> > Bert
> > 
> > > -----Original Message-----
> > > From: David Frascone [mailto:dave@frascone.com]
> > > Sent: Wednesday, January 24, 2001 11:43 AM
> > > To: sip@lists.bell-labs.com
> > > Subject: Re: [SIP] T2 and 182 Queued
> > > 
> > > 
> > > Ok, but let me get this straight.  This call flow looks like 
> > > it is broken
> > > with the current RFC.  Let me know if I am wrong.  It seems 
> > > broken even
> > > without a proxy.  In the following, I'm assuming a 20-30 
> > > minute queue wait.
> > > Not unreasonable if you've ever called customer support about 
> > > a DSL line :)
> > > 
> > > Ok, Here is a good call:
> > > 
> > >     UA1                             UA2
> > >      |                               |
> > >      |             INVITE            |
> > >      |------------------------------>|
> > >      |                               |
> > >      |      182 Queue Position 20    |
> > >      |<------------------------------|
> > >      |                               |
> > >      |      182 Queue Position 10    |
> > >      |<------------------------------|
> > >      |                               |
> > >      |      182 Queue Position 1     |
> > >      |<------------------------------|
> > >      |                               |
> > >      |            200 OK F4          |
> > >      |<------------------------------|
> > >      |                               |
> > >      |               ACK             |
> > >      |------------------------------>|
> > >      |                               |
> > >     UA1                             UA2
> > > 
> > > Everything is happy above.  But, what about this:
> > > 
> > > 
> > >     UA1                             UA2
> > >      |                               |
> > >      |             INVITE            |
> > >      |------------------------------>|
> > >      |                               |
> > >      |      182 Queue Position 120   |
> > >      |<------------------------------|
> > >      |                               |
> > >    Here, the UA1 pulls the plug on his computer, drives into a tunnel,
> > >    has a power outage, ISP drops the connection, etc.  No cancel, just
> > >    vanishes.
> > > 
> > >      |      182 Queue Position 110   |
> > >      |<------------------------------|
> > >      |                               |
> > >      |      182 Queue Position 100   |
> > >      |<------------------------------|
> > >      |                               |
> > >      |      182 Queue Position 1     |
> > >      |<------------------------------|
> > >      |                               |
> > >      |            200 OK F4          |
> > >      |<------------------------------|
> > >      |                               |
> > >      |   UA2 Timer FINALLY times out |
> > >      |                               |
> > >     UA1                             UA2
> > > 
> > > 
> > > So, the UA keeps him in the queue, spitting out UDP packets for a LONG
> > > time, without ever knowing that UA1 is no longer on the 
> > > network.  So, if
> > > T2 *is* used, the timeout is way too short.  If T2 is NOT 
> > > used, then there
> > > is an big waste of retransmissions for queued calls.  Perhaps 
> > > PRACK should be
> > > required for long queue times?  There might even be a DOS 
> > > attack by forging
> > > tons of INVITES to a full queue.
> > > 
> > > Now do you see the problem?  
> > > 
> > > 
> > > 
> > > On Wed, Jan 24, 2001 at 11:35:47AM +0200, Itamar Gilad wrote:
> > > > David,
> > > > 
> > > 
> > > 
> > > On Wed, Jan 24, 2001 at 11:35:47AM +0200, Itamar Gilad wrote:
> > > > David,
> > > > 
> > > > we found that on top of T1 and T2 there's a need for 
> > > "transaction timeouts"
> > > > i.e. a timer that terminates the transaction simply because nothing
> > > > significant happened for a given period of time. Note that 
> > > the durations of
> > > > these timeouts vary based on the current state of the 
> > > transaction. Without
> > > > these timeouts some transactions might never die. You can find some
> > > > references to this matter in RFC 2543-bis02. 
> > > > 
> > > >   Itamar 
> > > > 
> > > > > -----Original Message-----
> > > > > From: David Frascone [mailto:dave@frascone.com]
> > > > > Sent: Tue, January 23, 2001 9:44 PM
> > > > > To: sip@lists.bell-labs.com
> > > > > Subject: Re: [SIP] T2 and 182 Queued
> > > > > 
> > > > > 
> > > > > So, a proxy server would just retransmit the 182 
> > > > > indefinately?  I thought the
> > > > > proxy retransmission timer was also tied to T2.
> > > > > 
> > > > > Hehe, maybe I should just use TCP :)
> > > > > 
> > > > > On Tue, Jan 23, 2001 at 02:17:49PM -0500, Eric Tremblay wrote:
> > > > > > David,
> > > > > > 
> > > > > > 10.3.1 states that INVITES are retransmitted after T1 
> > > > > seconds, and this
> > > > > > value doubles after each retransmission.  Retransmissions 
> > > > > are stopped when
> > > > > > receiving any kind of response (provisional or definitive). 
> > > > >  As soon as a
> > > > > > UAC receives a 182, it simply stops retransmitting its 
> > > > > INVITE and waits for
> > > > > > a final response (which can take a lot of time to come).
> > > > > > 
> > > > > > EricT
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: David Frascone [mailto:dave@frascone.com]
> > > > > > > Sent: Monday, January 22, 2001 12:47
> > > > > > > To: sip@lists.bell-labs.com
> > > > > > > Subject: Re: [SIP] T2 and 182 Queued
> > > > > > > 
> > > > > > > 
> > > > > > > You are right.  I did copy the wrong paragraph.  But, I still 
> > > > > > > can't find 
> > > > > > > anywhere in 10.3 that stops the T2 timer.  It says that 
> > > > > > > provisional responses
> > > > > > > are re-sent upon every duplicate request, but it never resets 
> > > > > > > the T2 timer.
> > > > > > > 
> > > > > > > My concern is not retransmissions, but the total call setup 
> > > > > > > time, which 
> > > > > > > could take much longer than T2 allows, if the call is queued.
> > > > > > > 
> > > > > > > Now, if the timers are just a suggestion, and the user agent 
> > > > > > > can do whatever
> > > > > > > it wants, then this is not a problem.  I know that I can set 
> > > > > > > T1 and T2 to
> > > > > > > whatever values I want, but I'd prefer to have a queued call 
> > > > > > > work within
> > > > > > > the "suggested" parameters of 500ms and 4sec as set 
> > > by the RFC.
> > > > > > > 
> > > > > > > Comments?  Does anyone really care?  Should I ignore this, 
> > > > > > > and just set my
> > > > > > > T2 timer really high?
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Mon, Jan 22, 2001 at 05:29:45PM -0000, Jo Hornsby wrote:
> > > > > > > > David Frascone wrote:
> > > > > > > > > Given this forwarded discussion, this might be an 
> > > > > error in 02bis.
> > > > > > > > 
> > > > > > > > It might be.  But given the fact that section 10.2 
> > > is entitled:
> > > > > > > > "Reliability for Requests Other Than INVITE", I suspect it 
> > > > > > > is not. &:)
> > > > > > > > 
> > > > > > > > > ----- Forwarded message from Jo Hornsby 
> > > > > > > <jhornsby@ubiquity.net> -----
> > > > > > > > > 
> > > > > > > > > From: "Jo Hornsby" <jhornsby@ubiquity.net>
> > > > > > > > > To: "David Frascone" <dave@frascone.com>, 
> > > > > > > > > <sip-implementors@cs.columbia.edu>
> > > > > > > > > Subject: RE: [SIP] T2 and 182 Queued
> > > > > > > > > Date: Mon, 22 Jan 2001 15:47:36 -0000
> > > > > > > > > Message-ID: 
> > > <000001c0848a$a4281f20$4e34c3c1@ubiquity.co.uk>
> > > > > > > > > 
> > > > > > > > > David Frascone wrote:
> > > > > > > > > >
> > > > > > > > > > Does anyone know the answer to this?  Should I switch 
> > > > > > > to the sip list?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Fri, Jan 19, 2001 at 11:16:13AM -0600, David 
> > > > > Frascone wrote:
> > > > > > > > > > > From section 10.2.1:
> > > > > > > > > > >
> > > > > > > > > > >    Subsequent retransmissions are spaced by T2 
> > > > > > > seconds. If the client
> > > > > > > > > > >    receives a provisional response, it continues to 
> > > > > > > retransmit the
> > > > > > > > > > >    request, but with an interval of T2 seconds. 
> > > > > > > Retransmissions cease
> > > > > > > > > > >    when the client has sent a total of eleven 
> > > > > > > packets, or receives a
> > > > > > > > > > >    definitive response. Default values for T1 and 
> > > > > T2 are 500 
> > > > > > > > > ms and 4 s,
> > > > > > > > > > >    respectively. Clients MAY use larger values, but 
> > > > > > > SHOULDNOT use
> > > > > > > > > > >    smaller ones. Servers retransmit the response upon 
> > > > > > > receipt of a
> > > > > > > > > > >
> > > > > > > > > > > Which means, the INVITE would be retransmitted 
> > > > > every 4 seconds
> > > > > > > > > > > while the caller is waiting in the queue.  And, would 
> > > > > > > stop after
> > > > > > > > > > > 11 retransmissions, or 44 seconds, which is still too 
> > > > > > > small for
> > > > > > > > > > > some queues.
> > > > > > > > > 
> > > > > > > > > You are correct -- the text you quoted does say this. 
> > > > >  However,
> > > > > > > > > if you seek to the beginning of the same 
> > > paragraph, you find:
> > > > > > > > > 
> > > > > > > > >    A SIP client using an unreliable transport 
> > > > > protocol such as UDP
> > > > > > > > >    SHOULD retransmit requests other than INVITE 
> > > or ACK [...]
> > > > > > > > > 
> > > > > > > > > Look to section 10.3 for reliability-related behaviour 
> > > > > > > for INVITEs.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > >  - Jo.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > ----- End forwarded message -----
> > > > > > > > > 
> > > > > > > > > _______________________________________________
> > > > > > > > > This list is for continuing development of the 
> > > SIP protocol.
> > > > > > > > > The sip-implementer's list is the place to discuss 
> > > > > implementation,
> > > > > > > > > and to receive advice on understanding existing sip.
> > > > > > > > > To subscribe to it, send mail to 
> > > > > majordomo@cs.columbia.edu with
> > > > > > > > > "subscribe sip-implementors" in the body.
> > > > > > > > > 
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > This list is for continuing development of the SIP protocol.
> > > > > > > The sip-implementer's list is the place to discuss 
> > > implementation,
> > > > > > > and to receive advice on understanding existing sip.
> > > > > > > To subscribe to it, send mail to 
> > > majordomo@cs.columbia.edu with
> > > > > > > "subscribe sip-implementors" in the body.
> > > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > This list is for continuing development of the SIP protocol.
> > > > > > The sip-implementer's list is the place to discuss 
> > > implementation,
> > > > > > and to receive advice on understanding existing sip.
> > > > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > > > > "subscribe sip-implementors" in the body.
> > > > > 
> > > > > _______________________________________________
> > > > > This list is for continuing development of the SIP protocol.
> > > > > The sip-implementer's list is the place to discuss implementation,
> > > > > and to receive advice on understanding existing sip.
> > > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > > > "subscribe sip-implementors" in the body.
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > This list is for continuing development of the SIP protocol.
> > > > The sip-implementer's list is the place to discuss implementation,
> > > > and to receive advice on understanding existing sip.
> > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > > "subscribe sip-implementors" in the body.
> > > 
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementer's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > "subscribe sip-implementors" in the body.
> > > 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 15:00:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29284
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 15:00:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 749E34438B; Wed, 24 Jan 2001 14:01:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4])
	by lists.bell-labs.com (Postfix) with SMTP id 5349844336
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 14:00:36 -0500 (EST)
Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP (
 Tumbleweed MMS SMTP Relay (MMS v4.7)); Wed, 24 Jan 2001 11:59:41 -0800
X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900
Received: by mailserver.sylantro.com with Internet Mail Service (
 5.5.2653.19) id <DS5D56T8>; Wed, 24 Jan 2001 11:59:41 -0800
Message-ID: <79FEAA5FABA7D411BF580001023D1BBD26E239@mailserver.sylantro.com>
From: "Venkatesh Venkataramanan" <Venkatesh.Venkataramanan@sylantro.com>
To: "Michael Thomas" <mat@cisco.com>, "Bryan Byerly" <byerly@cisco.com>
Cc: "Venkatesh Venkataramanan" <Venkatesh.Venkataramanan@sylantro.com>,
        sip@lists.bell-labs.com
Subject: RE: [SIP] Announcements in SIP
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 1671EBA751576-01-01
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 11:59:39 -0800
Content-Transfer-Encoding: 7bit

Yes. I had suggested the usage of an alternate header instead of using
contact (something similar to Alert-Info header, say CallProgress-Info, or
rename Alert-Info to a more generic name like, CallProgress-Info) which can
indicate to the announcement server the announcement id to play.... Haven't
heard any response on that one :-)?

On seeing a 404 response, an end UA *may* choose to use the information in
the CallProgress-Info header if it is not capable of providing local
annoucements, otherwise, it could render to the user the information
provided in the CallProgress-Info header. How does this look?

-----Original Message-----
From: Michael Thomas [mailto:mat@cisco.com]
Sent: Wednesday, January 24, 2001 11:40 AM
To: Bryan Byerly
Cc: Venkatesh Venkataramanan; sip@lists.bell-labs.com
Subject: Re: [SIP] Announcements in SIP


Bryan Byerly writes:
 > The approach using a Contact in the response would also work for smart
 > UAs.
 > 
 > A              Po             Pt           AnnServer
 > |              |              |                |
 > |--INV Bob@Po->|              |                |
 > |              |--INV Bob@Pt->|                |
 > |              |              |                |
 > |              |<-404---------|                |
 > |              |              |                |
 > |<-404---------|              |                |
 > |  Contact: AnnServer         |                |
 > |              |              |                |
 > |--INV AnnServer------------------------------>|
 > |              |              |                |
 > |<-183/200-------------------------------------|
 > |              |              |                |
 > |<="The URL you have dialed B...O...B at Pt is=|
 > |   unrouteable, please check the URL or       |
 > |   contact your system admin for assistance"  |
 > 
 > 
 > 
 > However,
 > a) this doesn't provide an announcements solution for dumb UAs

   How so? It's the announcement server that has the
   smarts, right?

 > b) I doubt a smart UA would even need an AnnServer contact.  Since he's
 > smart, he would either 1) be able to generate annoucements locally or
 > 2) know the FQDN/IP address of the AnnServer directly.  I'm not aware
 > that smart UAs need any proxy assist. (Although, they would need to be
 > able to turn off proxy assist).

   It's not like the smart UA would need to be
   *forced* to use the contact header, right?
   If it thinks it can put on a better side show
   than the announcement server, nothing's
   stopping it, right?

 > 
 > In the proposal above, how would the Announcement server know to say
 > "B...O...B"?

   contact: sip:ann@foo.com?luser=bob

   or some such?

 > One solution would be for the Annoucement server to examine the
 > Diversion header (draft-levy-sip-diversion-01.txt).  The Diversion
 > header provides the necessary supplemental information to the
 > announcement server.  Since the Diversion header is already needed for
 > voicemail servers, I think it is a good candidate for usage here.

   The problem with the diversion header is that
   my UA never got a chance to, oh say, have my
   UA brew me another cup of coffee while I'm
   camping on Bob to become available. Instead,
   the *proxy* decided that for me, and as a 
   result I get no coffee to pacify me.

	    Mike


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 16:55:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01245
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 16:55:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7FE8F443A5; Wed, 24 Jan 2001 15:56:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cybertron.div8.net (HSE-Kitchener-ppp320923.sympatico.ca [64.231.176.170])
	by lists.bell-labs.com (Postfix) with ESMTP id 8901E44336
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 15:55:31 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m14LXtM-003ErcC@cybertron.div8.net> (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Wed, 24 Jan 2001 16:55:48 -0500 (EST) 
From: Billy Biggs <billy@billybiggs.com>
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com>,
        SIP List <sip@lists.bell-labs.com>
Subject: Re: [SIP] T2 and 182 Queued
Message-ID: <20010124165548.A673@div8.net>
References: <DBD1CC7CE357D211AECC009027158FD103BFE28B@itmail-ict1-imc.wichita.brite.com> <3A6F21B3.F9BC9612@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A6F21B3.F9BC9612@cs.columbia.edu>; from hgs@cs.columbia.edu on Wed, Jan 24, 2001 at 01:40:51PM -0500
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 16:55:48 -0500

Henning G. Schulzrinne (hgs@cs.columbia.edu):

> I suspect that in many cases, SUBSCRIBE/NOTIFY may be the more
> appropriate mechanism for ACD-like systems in the future.
> 
> Dumb PSTN gateways are never an excuse for falling back to silly audio
> signaling, with all its attendant problems.

  If a PSTN gateway receives a 182 Queued at Work (tag=5) and a 180
Ringing Home Phone (tag=8), what should it play to the user?  Can it
possibly generate audio to convey this information?

  It's important that all call states maps to machine-readable status
codes with error messages for many cool features.  However, in order to
personalize service, and for guarenteed compatibility with display-less
phones (PSTN), you need an audio stream: call queues need to play music,
ads, or explain how much they appreciate your call, and some find-me
services may wish to explain their progress as they locate your party.

  Using SIP, an audio stream is only established when a call is
successfully established.  Pre-call is a multi-party unconnected tree,
and no media is established on call failure.  I therefore suspect that
many systems in practice will connect the call as soon as possible to
allow for enhanced verbage in the audio stream.  Some find-me services
will using a back-to-back SIP UA instead of a pure forking proxy.

  Maybe a helpful technique would be to have a mid-call status code,
sent in a header in a re-INVITE, or some description language sent in
the body of a CALLSTATE message.  This may be useful to indicate a call
state change while still establishing a point-to-point connection and
allowing for media.  This way, gateways which need to send pre-connect
media may still be able to send back status updates if such information
becomes available, and back-to-back UAs can propagate back information
in the signalling domain.

  This isn't to say that informative 100-class responses, or even
informative 400-class responses are useless: only that for many
applications they will not be appropriate.


  One hint is how many websites use HTTP authentication, and how many do
their own nice-looking web page with text boxes.  Personalization of
service is important.

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 17:15:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01537
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 17:15:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 36CB8443C2; Wed, 24 Jan 2001 16:16:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id DFE5644336
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 16:15:53 -0500 (EST)
Received: (qmail 9873 invoked by uid 500); 24 Jan 2001 22:21:10 -0000
From: David Frascone <dave@frascone.com>
To: sip@lists.bell-labs.com
Message-ID: <20010124162110.B9844@newman.frascone.com>
Mail-Followup-To: sip@lists.bell-labs.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-encrypt-payload: no
Subject: [SIP] DoS attacks and UDP
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 16:21:10 -0600

Ok, not that I want to stir up the hornets' nest any more but . . .

It seems like the INVITE message is very susceptible to a DoS attack.  What's
to keep someone from generating hundreds of SIP INVITEs, and sending them
from bogus UDP addresses?

Even if the requests had SIP URLs that were not known, the server would spend
quite a bit of time retransmitting the 4xx response, which would never be
ACK'ed.

And, if it was a proxy, it might spend lots of time looking up domains, and
querying other servers, to only be spinning its wheels, and wasting valuable
CPU time.

Has anyone addressed this possibility?  Is there a draft that offers a
solution?  Perhaps a mandatory provisional response, and PRACK?

Or, is everyone else using TCP?


-Dave

P.S.  I have thought of using authentication, but that would only work
on your local sip proxy, not if you were trying to query sip.foo.com about
aaaaa1@foo.com, aaaaa2@foo.com, etc.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 17:43:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01764
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 17:43:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 596D8443B2; Wed, 24 Jan 2001 16:44:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id DAC1944336
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 16:43:12 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA07108;
	Wed, 24 Jan 2001 17:42:58 -0500 (EST)
Message-ID: <3A6F5A72.FD4D542D@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: David Frascone <dave@frascone.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] DoS attacks and UDP
References: <20010124162110.B9844@newman.frascone.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 17:42:58 -0500
Content-Transfer-Encoding: 7bit

IPsec has a anti-clogging mechanism, but any such mechanism requires
additional round-trip times, by definition. You can also do a 3xx to a
TCP connection...

PRACK doesn't help here.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 17:45:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01777
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 17:45:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AE912443CB; Wed, 24 Jan 2001 16:46:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id DC166443CB
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 16:45:20 -0500 (EST)
Received: (qmail 9991 invoked by uid 500); 24 Jan 2001 22:50:39 -0000
From: David Frascone <dave@frascone.com>
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] DoS attacks and UDP
Message-ID: <20010124165038.B9924@newman.frascone.com>
Mail-Followup-To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
	sip@lists.bell-labs.com
References: <20010124162110.B9844@newman.frascone.com> <3A6F5A72.FD4D542D@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A6F5A72.FD4D542D@cs.columbia.edu>; from hgs@cs.columbia.edu on Wed, Jan 24, 2001 at 05:42:58PM -0500
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 16:50:38 -0600

I guess you're right.  The retransmission timer on the PRACK is the same as
on the invite.

On Wed, Jan 24, 2001 at 05:42:58PM -0500, Henning G. Schulzrinne wrote:
> IPsec has a anti-clogging mechanism, but any such mechanism requires
> additional round-trip times, by definition. You can also do a 3xx to a
> TCP connection...
> 
> PRACK doesn't help here.
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 17:50:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01828
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 17:50:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4ABB5443D0; Wed, 24 Jan 2001 16:51:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id D0E42443CA
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 16:50:01 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA07629;
	Wed, 24 Jan 2001 17:49:38 -0500 (EST)
Message-ID: <3A6F5C02.FD639C62@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Billy Biggs <billy@billybiggs.com>
Cc: "Culpepper, Bert" <bert.culpepper@intervoice-brite.com>,
        SIP List <sip@lists.bell-labs.com>
Subject: Re: [SIP] T2 and 182 Queued
References: <DBD1CC7CE357D211AECC009027158FD103BFE28B@itmail-ict1-imc.wichita.brite.com> <3A6F21B3.F9BC9612@cs.columbia.edu> <20010124165548.A673@div8.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 17:49:38 -0500
Content-Transfer-Encoding: 7bit

We should design mechanisms that give people reasons to move away from
legacy PSTN systems rather than assume that all future VoIP will be
limited to whatever limitations the current steam telephones have.

However, this seems like a caller preferences item, where the caller can
indicate whether it wants audio feedback or something more semantically
meaningful. Indeed, the caller preferences draft already contains this
feature:

    queue-feature: If the called party is temporarily unreachable,
             e.g., because it is in another call, the caller can
             indicate that it wants to have its call queued rather than
             rejected immediately. If the call is queued, the server
             returns "182 Queued".  A pending call be terminated by a
             SIP CANCEL or BYE request.

We may want to rephrase/add a third option, as in "queue, but connect to
elevator music and being forced to listen to advertisements".
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 17:53:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01873
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 17:53:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B6F1D443CA; Wed, 24 Jan 2001 16:54:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 884D7443C6
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 16:53:55 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA07842;
	Wed, 24 Jan 2001 17:53:41 -0500 (EST)
Message-ID: <3A6F5CF5.EBE32AAC@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: David Frascone <dave@frascone.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] DoS attacks and UDP
References: <20010124162110.B9844@newman.frascone.com> <3A6F5A72.FD4D542D@cs.columbia.edu> <20010124165038.B9924@newman.frascone.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 17:53:41 -0500
Content-Transfer-Encoding: 7bit

David Frascone wrote:
> 
> I guess you're right.  The retransmission timer on the PRACK is the same as
> on the invite.

If anything, reliable prov. responses make the problem worse, not
better. Also, the UAC indicates whether it wants that feature, so one
cannot rely on it to do anything that the UAC may not be interested in.

> 
> On Wed, Jan 24, 2001 at 05:42:58PM -0500, Henning G. Schulzrinne wrote:
> > IPsec has a anti-clogging mechanism, but any such mechanism requires
> > additional round-trip times, by definition. You can also do a 3xx to a
> > TCP connection...
> >
> > PRACK doesn't help here.
> > --
> > Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 19:40:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02587
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 19:40:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8C98E443C6; Wed, 24 Jan 2001 18:41:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj_ntserver3.sj.nuera.com (h-207-20-110-62.ncal.verio.net [207.20.110.62])
	by lists.bell-labs.com (Postfix) with ESMTP id 5180F44336
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 18:40:39 -0500 (EST)
Received: by sj_ntserver3.sj.nuera.com with Internet Mail Service (5.5.2650.21)
	id <CWGVGJ5C>; Wed, 24 Jan 2001 16:40:25 -0800
Message-ID: <DD70FD1C981BD411B64400508BA547C1049E28@sj_ntserver3.sj.nuera.com>
From: "Emami-Nouri, Mohsen" <memami@nuera.com>
To: "'Rick Dean'" <siplist@fdd.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] draft-ietf-sip-handoff-00pre8.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 16:40:18 -0800

Hi,
If we were to totally summarize the difference between REFER and HANDOFF,
would it be close if we said HANDOFF is a asynchronous and REFER is a
synchronous call transfer model?.

-----Original Message-----
From: Rick Dean [mailto:siplist@fdd.com]
Sent: Wednesday, January 17, 2001 10:27 AM
To: sip@lists.bell-labs.com
Subject: [SIP] draft-ietf-sip-handoff-00pre8.txt



Dear SIP list,

Although we would like more time to 
edit this poor draft, we feel a sneak
peek is warranted due to its urgent nature
with the upcomming meeting.

http://phonectl.sfour.com/draft-ietf-sip-handoff-00pre8.txt

Some significant differences from REFER are:
  * narrower scope
  * method completes without prompting
  * referred-by like header generated by transferee
  * location of headers for spawned invite
  * error processing & final notification

Cheers,
Rick
rick_dean@3com.com


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 24 19:44:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02619
	for <sip-archive@odin.ietf.org>; Wed, 24 Jan 2001 19:44:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 07702443DB; Wed, 24 Jan 2001 18:45:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160])
	by lists.bell-labs.com (Postfix) with ESMTP id 2863F44336
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 18:44:02 -0500 (EST)
Received: from tot-mtc-td.proxy.aol.com (tot-mtc-td.proxy.aol.com [64.12.104.131])
	  by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0)
	  with ESMTP id TAA26660 for <sip@lists.bell-labs.com>;
	  Wed, 24 Jan 2001 19:43:29 -0500 (EST)
Received: from eburger (ACA8A671.ipt.aol.com [172.168.166.113])
	by tot-mtc-td.proxy.aol.com (8.10.0/8.10.0) with SMTP id f0P0hRq13153
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 19:43:28 -0500 (EST)
From: "Eric Burger" <eburger@snowshore.com>
To: <sip@lists.bell-labs.com>
Subject: RE: [SIP] Announcements in SIP
Message-ID: <NEBBLACLCLHMJBCAJGOEOEJDCJAA.eburger@snowshore.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <79FEAA5FABA7D411BF580001023D1BBD26E239@mailserver.sylantro.com>
X-Apparently-From: Eburger3@aol.com
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 19:43:47 -0500
Content-Transfer-Encoding: 7bit

If it can be done (getting around the 4xx response issue), it look great.
Rather than recreating the bugs (I mean features :-) of the PSTN [sending
aural signaling in-band as "early media"], we provide useful solutions to
end users [providing informative responses, using local resources when
possible or network resources if necessary].

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Venkatesh
> Venkataramanan
> Sent: Wednesday, January 24, 2001 3:00 PM
> To: Michael Thomas; Bryan Byerly
> Cc: Venkatesh Venkataramanan; sip@lists.bell-labs.com
> Subject: RE: [SIP] Announcements in SIP
>
>
> Yes. I had suggested the usage of an alternate header instead of using
> contact (something similar to Alert-Info header, say CallProgress-Info, or
> rename Alert-Info to a more generic name like, CallProgress-Info)
> which can
> indicate to the announcement server the announcement id to
> play.... Haven't
> heard any response on that one :-)?
>
> On seeing a 404 response, an end UA *may* choose to use the information in
> the CallProgress-Info header if it is not capable of providing local
> annoucements, otherwise, it could render to the user the information
> provided in the CallProgress-Info header. How does this look?
>
[snip]


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 00:13:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07625
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 00:13:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A770244338; Wed, 24 Jan 2001 23:14:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id C7CA244336
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 23:13:46 -0500 (EST)
Received: (qmail 10983 invoked by uid 500); 25 Jan 2001 05:19:09 -0000
From: David Frascone <dave@frascone.com>
To: sip@lists.bell-labs.com
Subject: Re: [SIP] DoS attacks and UDP
Message-ID: <20010124231909.E10080@newman.frascone.com>
Mail-Followup-To: sip@lists.bell-labs.com
References: <20010124162110.B9844@newman.frascone.com> <14959.23140.85557.164591@thomasm-u1.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <14959.23140.85557.164591@thomasm-u1.cisco.com>; from mat@cisco.com on Wed, Jan 24, 2001 at 02:42:44PM -0800
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 23:19:09 -0600

So, when do you think that a global PKI infrastructure will be in place?  I
had assumed it was still pretty far away.  The infrastructure would have to
be available to ANYONE globally and work with ANY sip server.

I agree that my post would be moot with a global PKI in place, so, if you'll
just send me a pointer to information on the PKI infrastructure, I'll consider
this discussion closed.

But, until then, there is a nasty DoS vunerability in SIP over UDP.

-Dave

On Wed, Jan 24, 2001 at 02:42:44PM -0800, Michael Thomas wrote:
> David Frascone writes:
>  > Ok, not that I want to stir up the hornets' nest any more but . . .
>  > 
>  > It seems like the INVITE message is very susceptible to a DoS attack.  What's
>  > to keep someone from generating hundreds of SIP INVITEs, and sending them
>  > from bogus UDP addresses?
> 
>    Crypto.
> 
> 			Mike

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 00:15:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07684
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 00:15:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E3D4944345; Wed, 24 Jan 2001 23:16:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id D4CE944336
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 23:15:54 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA10575;
	Thu, 25 Jan 2001 00:18:26 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9K2TJA>; Thu, 25 Jan 2001 00:12:10 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BFB9809D@DYN-EXCH-001.dynamicsoft.com>
From: Igor Slepchin <ISlepchin@dynamicsoft.com>
To: "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] T2 and 182 Queued
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 00:12:09 -0500

1. If the UAC is gone, the UAS will get an ICMP error on the second
retransmission of 182 and is free to drop the call after that.
2. Whether UAS queues up messages for 10 or 100 minutes is not very
relevant; a DOS attack just requires somewhat less resources in the first
case than in the second. There is nothing SIP-specific in attacks that flood
the service provider with bogus messages.

---
Igor Slepchin


> -----Original Message-----
> From: David Frascone [mailto:dave@frascone.com]
> Sent: Wednesday, January 24, 2001 1:11 PM
> To: sip@lists.bell-labs.com
> Subject: Re: [SIP] T2 and 182 Queued
> 
> 
> This bounced when Pat tried to send it, so I'm forwarding it.  
> 
> ----- Forwarded message from Pat Calhoun <pcalhoun@eng.sun.com> -----
> 
> Date: Wed, 24 Jan 2001 09:15:44 -0800 (PST)
> From: Pat Calhoun <pcalhoun@eng.sun.com>
> Reply-To: Pat Calhoun <pcalhoun@eng.sun.com>
> Subject: Re: [SIP] T2 and 182 Queued
> To: David Frascone <dave@frascone.com>
> Cc: sip@lists.bell-labs.com
> Message-ID: <Roam.SIMC.2.0.6.980356544.32567.pcalhoun@nasnfs>
> 
> > 
> > Everything is happy above.  But, what about this:
> > 
> > 
> >     UA1                             UA2
> >      |                               |
> >      |             INVITE            |
> >      |------------------------------>|
> >      |                               |
> >      |      182 Queue Position 120   |
> >      |<------------------------------|
> >      |                               |
> >    Here, the UA1 pulls the plug on his computer, drives 
> into a tunnel,
> >    has a power outage, ISP drops the connection, etc.  No 
> cancel, just
> >    vanishes.
> > 
> >      |      182 Queue Position 110   |
> >      |<------------------------------|
> >      |                               |
> >      |      182 Queue Position 100   |
> >      |<------------------------------|
> >      |                               |
> >      |      182 Queue Position 1     |
> >      |<------------------------------|
> >      |                               |
> >      |            200 OK F4          |
> >      |<------------------------------|
> >      |                               |
> >      |   UA2 Timer FINALLY times out |
> >      |                               |
> >     UA1                             UA2
> > 
> > 
> > So, the UA keeps him in the queue, spitting out UDP packets 
> for a LONG
> > time, without ever knowing that UA1 is no longer on the 
> network.  So, if
> > T2 *is* used, the timeout is way too short.  If T2 is NOT 
> used, then there
> > is an big waste of retransmissions for queued calls.  
> Perhaps PRACK should be
> > required for long queue times?  There might even be a DOS 
> attack by forging
> > tons of INVITES to a full queue.
> > 
> > Now do you see the problem?  
> 
> Putting aside the obvious case of wasted resources, I think 
> that the potential
> for denial of service attacks is THE reason why this is 
> broken. Imagine
> competitor A issuing a UDP based IP address spoofing attack 
> on competitor B,
> filling up their call queues. With the number of calls, the 
> queue will quickly
> fill up, so I believe it is a MUST that the 182 messages be 
> ack'ed, to reduce
> the queue size. This should be a MUST, regardless of the wait time.
> 
> I think that proofing against DoS attacks should be a high 
> priority item for
> the WG.
> 
> PatC
> 
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 00:19:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07701
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 00:19:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A493344352; Wed, 24 Jan 2001 23:20:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 3AD5E4434F
	for <sip@lists.bell-labs.com>; Wed, 24 Jan 2001 23:19:28 -0500 (EST)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id VAA22896;
	Wed, 24 Jan 2001 21:19:24 -0800 (PST)
Received: from sony-laptop (ssh-sj1.cisco.com [171.68.225.134])
	by imop.cisco.com (Mirapoint)
	with SMTP id AAI33776;
	Wed, 24 Jan 2001 21:19:11 -0800 (PST)
Message-Id: <4.1.20010124210806.00b652e0@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
To: Rick Dean <siplist@fdd.com>, sip@lists.bell-labs.com
From: Rohan Mahy <rohan@cisco.com>
In-Reply-To: <20010124104917.A27867@fdd.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [SIP] Re: REFER issues
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 24 Jan 2001 21:26:07 -0800

Hi folks,

Following in Rick's footsteps...  Billy's private comments are likewise
removed.  I'm happy to move the rest of this thread to the list.

At 08:49 AM 1/24/01 , Rick Dean wrote:
>
>Dear SIP list,
>
>I apologize for only publishing my side of
>this debate, but I feel right publishing
>other people private correspondence.  I need
>to publish my comments, so I don't
>to endlessly repeat myself in many conversations.
>
>--
>Rick
>
>> Rohan,
>> 
>> Thank you for your thoughts.  I wrote this off line last night.
>>
>> I agree HANDOFF is very late in comming.  Hopefully, not too
>> late.  It would mean some abandoned REFER work for me as well.
>> 
>> I would be powerful if a remote host forwards all of its sniffed
>> packets to me, and the remote sends any packet I forward to
>> it.  Admittedly extreme, but not only would it ignore security and
>> privacy, it has implemented nothing.  The work has simply
>> been moved around.

agreed.  IMO the hardest part of the work is defining the trust
relationships for the parties involved in features.
 
>> Without a layered architecture, I don't know how to assign
>> the functionality of HANDOFF and PhoneControl to different
>> programmers using REFER.  If we can cleanly separate these
>> two, should we?

on the UAC side the work is independent in that each programmer just
creates the appropriate Refer-To URL and adds any special case error handling.

on the UAS side, you do the work to support the primitive and parse the URL
once, then the work is in adding something like an access-list definition,
or sandbox definition for the additional functionality.

>> The syntax of REFER is more complicated.  Do you know when to escape?
>> How about REFER with a method=refer?  The readability of
>> SIP is lost.

yes, this is an admitted drawback.  You have to be able to read URLs and
then imagine what will happen to the bubbles based on the headers in the
Refer-To URL (not the easiest).  escaping should be done once for an
implementation of REFER, so it is complex for writing only once.

>> What kinds of security precautions should I put in my
>> REFER implementation?   If there is a level less than root,
>> what should it do with headers it doesn't recognize?
>> How many pages is your sandbox design?  ...and megabytes of
>> code?  .... or bug reports?

a sandbox design should be 2-5 pages.  In some cases it can be just a few
paragraphs.  It is like the section in HANDOFF where you guys explicitly
defined some illegal things (methods, call-id, etc...).  Each primitive
will need this code as apropos for its application.  We're not talking
about a lot of code if you do it well.  
 
>> If I already implement PhoneControl to talk to a PDA or
>> PC helper app, should I also support a REFER duplicate?
>> ...or should the PDA and PC have a full SIP parser
>> and their developers be SIP experts?

for that application, phonectl is still a reasonable model.  we need full
coverage, but some overlap of functionality isn't the end of the world.
 
>> If we remove HANDOFF, PhoneControl, and JOIN functionality
>> from REFER,  what is left?   (Hopefully nobody ever drafts JOIN.)

see our further discussion on TAKE....

>> 
>> --
>> Rick
>> 
>> BTW, the join wording of PHONECTL was changed to handoff.  Some
>> typos were fixed.   http://phonectl.sfour.com/


------------
A previous reply to Rick's other post....
>>Rohan,
>>
>>Agreed that TAKE is another primitive supported
>>by REFER, but not covered in the other drafts.
>>I reject REFER in part because I don't want TAKE.
>>
>>Without PHONECTL access, how do I know about the
>>call leg I am going to take?  
>
>Choice 1: you were originally a party to the call so you know it's call-id.  
>presumably your original role in the call gives you some rights in certain 
>circumstances automatically.  I almost certainly don't want to give phonectl 
>style control to you just because we were in a call together once.
>
>Choice 2: you are already a trusted role/entity in the network.  I probably 
>don't want you to be able to do phonectl things to me.  call center take, 
>and operator barge-in needs one role (supervisors, attendants, operators) to 
>be able to ask special things of another role (the agents/ordinary users).
>
>Note that I may use PHONECTL to control my desk phone, which I use as as a 
>call center agent, and for regular business calls. Based on my role, I am 
>willing to grant permission to my phone to let an authenticated category of 
>folks (supervisors) tell the phone to do rude things to my call-legs 
>occasionally, but only for my call center persona.  Likewise these same 
>folks should be able to SUBSCRIBE to certain things (this may be the same 
>group of Events that PHONECTLs companion subscriptions use). 
>
>>Do you expect a
>>subscription to allow me to see all of someone
>>else's SIP traffic?   
>
>Absolutely not.  
>
>>Heck, with that why not forge
>>BYE and HANDOFF messages in the call-leg?
>
>I can already do that anyway if I can see your packets, and that is pretty 
>easy.  We need SIP message integrity and authentication anyway.  
>
>>Will your UA handoff a call to another with
>>the expectation of being able to take it back?
>
>sometimes.  a music on hold server is an automaton. like conferencing 
>servers, it would be reasonable to explicitly design automatons such that 
>you can undo anything you ask them to do.  you can make this behavior 
>explicit in a spec.  this is a very different thing from asking you to cease 
>talking to billy and talk to me now, just because sometime in the past I 
>transfered you to him.
>
>>What if the remote entity doesn't cooperate?
>
>it's allowed to refuse, just like it can refuse an INVITE or a BYE.  all 
>call control features in a peer to peer environment must be based on mutual 
>cooperation for mutual benefit.
>
>>You won't learn until too late.  The error
>>message would be comical.  With my envisioned
>>TAKE scenarios, the participants are too
>>altruistic.
>>
>>Taking back a call from a music-on-hold server
>>would be slower than ending a B2BUA.  
>
>cooperation takes time, just like in real life ;-)
>
>I do think we can make these flows reasonable for the common cases; even 
>with 100ms rtts.
>
>>Please don't
>>assume every network device is within a 20ms ping time.
>>I like to count by 100ms, and this doesn't assume loss.
>>
>>We are working on a draft for pickup.  The current
>>designs require a centralized privledged server.
>>I don't totally like them.  Maybe a TAKE
>>method would be good for this for rining calls only.
>>Nonetheless, the action of reviewing ringing
>>calls and instructing one to transfer is better
>>suited by a remote control layer, e.g. phonectl.
>>
>>To support phone provisioned pickup privledges, wouldn't
>>you need to modify some user interface.  At this
>>time wouldn't the SIP be modified to support it?
>>I don't buy your arguement against needing to code
>>additional methods being a problem.
>
>It's not a problem, but it effectively neautralizes the gain you champion of 
>small code size for your more numerous individual primitives.
>
>>Thank you for hearing me out.
>
>hey, this is fun.  i've been trying to get people to talk about features for 
>A LONG TIME, and there finally appears to be some interest.  :-)
>
>take care,
>-r
>
>>--
>>Rick
>>
>>
[snip]

>>> >> Seriously, I think we can put a security sandbox around your REFER
>>> >> security concerns, and nail down explicit Replaces, Joins, Fork-with
>>> >> or other headers that indicate the relationship of the triggered
>>> >> INVITE to existing call[ leg]s.

[like what?]

>>> having to authorize other methods, arbitrary call-ids, arbitrary headers,
>>> etc...
>>> 
>>> >> If HANDOFF was the first attempt to solve the transfer problem, I
>>> >> would have endorsed it wholeheartedly.  Now that I see what it can do,
>>> >> I don't want to give up the power of REFER. In either case I will
>>> >> yield to consensus.
>>> >
>>> >> FYI: I'm attaching some notes on call primitives based on "the bubble
>>> >> model" of a call.  Each primitive does not need to map onto a SIP
>>> >> method.  Each "primitive" corresponds to a distinct way to move
>>> >> parties in and out of call bubbles...

>>> draw ovals (bubbles) representing all the folks you want to be a "call".
>>> the basic operations on the bubbles are adding, removing, and replacing
>>> parties; and joining and spliting bubbles.  The primitives that I described
>>> (I picked an arbitrary breakdown of them, but close to a complete
>>> breakdown) are grouped based on what I consider to be the "interesting"
>>> part of the problem, which is authorization.
>>> 
>>> who should be allowed to take a call?  you shouldn't need authorization to
>>> do phonectl for every application of take.  You should be able to
>>> "takeback" a call that was yours in some circumstances.  Some trusted peers
>>> should be able to take some calls, but not all (your supervisor can take
>>> calls from you call center agent persona, but not from your personal
>>> persona.)  Hopefully you get the idea here.

>INVITE	BYE
>a originates	a or b originates
>a => a-b	a-b => a
>
>18x (progress) 	200 (accept)
>
>HANDOFF	TAKE
>	a-b => b-c
>a originates	c originates
>		could be used to retrieve parked call, call held with music, call center
take...
>		voice browser/voicemail yanking-back call
>
>		REFER or Interrupt
>
>		can take calls you used to be a party to (generate a takeback token)
>		also trusted 3rd parties...
>
>ADD		DROP
>a-b => a-b-c	a-b-c => a-b
>	originated by a or b
>with local mixing, just local implementation
>
>in full mesh, add is an INVITE with members header
>no way to "banish" a party for full mesh
>
>in conf bridge environment, how do I find out who is currently in the
>conference (SUB/NTFY).  how do I remotely add, drop, and mute them?
>
>	sip:conference-server;method=REFER?refer-to=<C;method=BYE> (drop)
>
>who should get to do this?  conference owner(s)
>
>FORK			INSERT
>a-b => a-b & a-c	a-b => a-b-c
>	originated by c
>mixed locally
>- originated by a:  just do it
>- originated by c:  Interruption.......
>conf bridge
>- originated by a: ask conf to do it
>- originated by c:  either Interrupt a (who asks conf), or ask conf
>directly (REFER)
>
>same rules as for take....
>
>conf - a, b, c  


etc.
>>> The problem with most primitives that purports to do conferencing, is that
>>> they rarely work for all four conferencing topologies:  conf bridge, local
>>> n-way mixing, full mesh, multicast conf.  If it doesn't, you end up
>>> frequently with REFER/HANDOFF to something else.


more rants...
>Little "c" conferencing isn't a feature, it is a basic services that you use 
>to build other features.  If you want to build features that involve more 
>than 3 simultaneous parties, then chances are you need conference control.  
>I don't give a rat's ass about floor control, voting, side channels, etc  as 
>defined in a traditional Conferencing System.  I just want to build the 
>features.  For that matter, we also need forking (multi-unicast) as a basic 
>service.
>
>Here are some examples of features that need conference or forking 
>primiitives (join isn't sufficient):
>
>	screening your voice mail
>	residential line emulation (classic use of full-mesh or multicast)
>	call center monitoring (supervisor or recording)
>	call center coaching
>	any of the examples I gave for TAKE.
>
>hope this helps...
>
>thanks,
>-rohan


Back to Rick:
>> Rohan,
>> 
>> Agreed that TAKE is another primitive supported
>> by REFER, but not covered in the other drafts.
>> I reject REFER in part because I don't want TAKE.
>> 
>> Without PHONECTL access, how do I know about the
>> call leg I am going to take?  Do you expect a
>> subscription to allow me to see all of someone
>> else's SIP traffic?   Heck, with that why not forge
>> BYE and HANDOFF messages in the call-leg?
>> 
>> Will your UA handoff a call to another with
>> the expectation of being able to take it back?
>> What if the remote entity doesn't cooperate?
>> You won't learn until too late.  The error
>> message would be comical.  With my envisioned
>> TAKE scenarios, the participants are too
>> altruistic.
>> 
>> Taking back a call from a music-on-hold server
>> would be slower than ending a B2BUA.  Please don't
>> assume every network device is within a 20ms ping time.
>> I like to count by 100ms, and this doesn't assume loss.
>> 
>> We are working on a draft for pickup.  The current
>> designs require a centralized privledged server.
>> I don't totally like them.  Maybe a TAKE
>> method would be good for this for rining calls only.
>> Nonetheless, the action of reviewing ringing
>> calls and instructing one to transfer is better
>> suited by a remote control layer, e.g. phonectl.
>> 
>> To support phone provisioned pickup privledges, wouldn't
>> you need to modify some user interface.  At this
>> time wouldn't the SIP be modified to support it?
>> I don't buy your arguement against needing to code
>> additional methods being a problem.
>> 
>> Thank you for hearing me out.
>> 
>> --
>> Rick
>> 
> 


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 02:21:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21572
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 02:21:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4F1144433C; Thu, 25 Jan 2001 01:22:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 39EE644336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 01:21:31 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0P7LLB03981;
	Thu, 25 Jan 2001 01:21:21 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: "Emami-Nouri, Mohsen" <memami@nuera.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
Message-ID: <20010125012120.A12953@fdd.com>
References: <DD70FD1C981BD411B64400508BA547C1049E28@sj_ntserver3.sj.nuera.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <DD70FD1C981BD411B64400508BA547C1049E28@sj_ntserver3.sj.nuera.com>; from memami@nuera.com on Wed, Jan 24, 2001 at 04:40:18PM -0800
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 01:21:20 -0600


Sorry, the authors of HANDOFF don't see a 
sync vs. async issue.  With both methods 
the initial transaction completes before
the spawned request does, and both have a 
means of conveying final status.

As for a sound bite difference, we would say "scope".
HANDOFF, PhoneControl, JOIN, TAKE, and a few other
methods (hopefully never to be defined) are replaced
by REFER and a sandbox.  We believe reduced scope
and simplified syntax make HANDOFF easier to implement
and will improve compatibility.

--
Rick
3Com


On Wed, Jan 24, 2001 at 04:40:18PM -0800, Emami-Nouri, Mohsen wrote:
> Hi,
> If we were to totally summarize the difference between REFER and HANDOFF,
> would it be close if we said HANDOFF is a asynchronous and REFER is a
> synchronous call transfer model?.
> 
> -----Original Message-----
> From: Rick Dean [mailto:siplist@fdd.com]
> Sent: Wednesday, January 17, 2001 10:27 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] draft-ietf-sip-handoff-00pre8.txt
> 
> 
> 
> Dear SIP list,
> 
> Although we would like more time to 
> edit this poor draft, we feel a sneak
> peek is warranted due to its urgent nature
> with the upcomming meeting.
> 
> http://phonectl.sfour.com/draft-ietf-sip-handoff-00pre8.txt
> 
> Some significant differences from REFER are:
>   * narrower scope
>   * method completes without prompting
>   * referred-by like header generated by transferee
>   * location of headers for spawned invite
>   * error processing & final notification
> 
> Cheers,
> Rick
> rick_dean@3com.com
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 07:33:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24299
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 07:33:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id ABDCE4434A; Thu, 25 Jan 2001 06:34:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web1401.mail.yahoo.com (web1401.mail.yahoo.com [128.11.23.165])
	by lists.bell-labs.com (Postfix) with SMTP id AEE6844341
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 06:33:52 -0500 (EST)
Received: (qmail 17623 invoked by uid 60001); 25 Jan 2001 12:33:39 -0000
Message-ID: <20010125123339.17622.qmail@web1401.mail.yahoo.com>
Received: from [206.82.141.26] by web1401.mail.yahoo.com; Thu, 25 Jan 2001 04:33:39 PST
From: zeeshan razzaque <zrazzaque@yahoo.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] ISUP Tunneling
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 04:33:39 -0800 (PST)

Hello,
Could someone plz guide me as to what is the standard
or most common way of tunneling ISUP messages through
SIP. Thanx.
Zeeshan.

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices. 
http://auctions.yahoo.com/

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 07:42:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24496
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 07:42:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5A41B4435A; Thu, 25 Jan 2001 06:43:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by lists.bell-labs.com (Postfix) with ESMTP id 48D0D44341
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 06:42:50 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f0PCgYd00116;
	Thu, 25 Jan 2001 13:42:35 +0100 (MET)
Received: from lmf.ericsson.se (E005004B52C74.lmf.ericsson.se [131.160.30.73])
	by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA18633;
	Thu, 25 Jan 2001 14:42:29 +0200 (EET)
Message-ID: <3A701F37.E3E2C535@lmf.ericsson.se>
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: zeeshan razzaque <zrazzaque@yahoo.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] ISUP Tunneling
References: <20010125123339.17622.qmail@web1401.mail.yahoo.com>
Content-Type: multipart/mixed;
 boundary="------------548FAD326698C0750539AB1C"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 14:42:31 +0200

This is a multi-part message in MIME format.
--------------548FAD326698C0750539AB1C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi,

You use the ISUP MIME message body.

http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-mime-07.txt

Regards,

Christer Holmberg
Ericsson Finland



zeeshan razzaque wrote:
> 
> Hello,
> Could someone plz guide me as to what is the standard
> or most common way of tunneling ISUP messages through
> SIP. Thanx.
> Zeeshan.
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - Buy the things you want at great prices.
> http://auctions.yahoo.com/
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
--------------548FAD326698C0750539AB1C
Content-Type: text/x-vcard; charset=us-ascii;
 name="christer.holmberg.vcf"
Content-Description: Card for Christer Holmberg
Content-Disposition: attachment;
 filename="christer.holmberg.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard 
n:Holmberg;Christer
tel;cell:+358-40-5604412
tel;work:+358-9-2992943
x-mozilla-html:FALSE
org:Ericsson;IP Multimedia / Advanced Signalling Research Laboratory
adr:;;;;;;
version:2.1
email;internet:christer.holmberg@lmf.ericsson.se
title:System Designer
fn:Christer Holmberg
end:vcard

--------------548FAD326698C0750539AB1C--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 09:55:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27729
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 09:55:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 35C7D44341; Thu, 25 Jan 2001 08:56:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from tnnt3.tachion.com (unknown [198.139.117.130])
	by lists.bell-labs.com (Postfix) with ESMTP id D703144336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 08:55:38 -0500 (EST)
Received: by TNNT3 with Internet Mail Service (5.5.2650.21)
	id <Z6CV7QZ0>; Thu, 25 Jan 2001 09:55:21 -0500
Message-ID: <5E7936641DC2D411B89900D0B7B92FBB1AC0CF@TNNT3>
From: Jaime Jimenez <jjimenez@tachion.com>
To: sip@lists.bell-labs.com
Subject: RE: [SIP] Announcements in SIP
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C086DE.D6D052D4"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 09:55:20 -0500

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_01C086DE.D6D052D4
Content-Type: text/plain;
	charset="iso-8859-1"

I am new to this list and I have a quick question on this item.

Are we looking to provide "in-band" Announcements for what traditionally
been call "network announcements?"  In the US PSTN we are required to
provide "answer supervision" (meaning to answer the call) before a
"customer" announcement can be played to the calling party. So if the call
is queued, then the call needs to be answered before a message can be
provided.

Having said that, there are other scenarios where the "network" can provide
recorded announcements (congestion, etc.) that are provided, but letting the
end system map that locally maybe the best approach.

Jaime


If it can be done (getting around the 4xx response issue), it look great.
Rather than recreating the bugs (I mean features :-) of the PSTN [sending
aural signaling in-band as "early media"], we provide useful solutions to
end users [providing informative responses, using local resources when
possible or network resources if necessary].

> On seeing a 404 response, an end UA *may* choose to use the information in
> the CallProgress-Info header if it is not capable of providing local
> annoucements, otherwise, it could render to the user the information
> provided in the CallProgress-Info header. How does this look?
>
[snip]




------_=_NextPart_001_01C086DE.D6D052D4
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2650.12">
<TITLE>RE: [SIP] Announcements in SIP</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I am new to this list and I have a quick question on =
this item.</FONT>
</P>

<P><FONT SIZE=3D2>Are we looking to provide &quot;in-band&quot; =
Announcements for what traditionally been call &quot;network =
announcements?&quot;&nbsp; In the US PSTN we are required to provide =
&quot;answer supervision&quot; (meaning to answer the call) before a =
&quot;customer&quot; announcement can be played to the calling party. =
So if the call is queued, then the call needs to be answered before a =
message can be provided.</FONT></P>

<P><FONT SIZE=3D2>Having said that, there are other scenarios where the =
&quot;network&quot; can provide recorded announcements (congestion, =
etc.) that are provided, but letting the end system map that locally =
maybe the best approach.</FONT></P>

<P><FONT SIZE=3D2>Jaime</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>If it can be done (getting around the 4xx response =
issue), it look great.</FONT>
<BR><FONT SIZE=3D2>Rather than recreating the bugs (I mean features :-) =
of the PSTN [sending</FONT>
<BR><FONT SIZE=3D2>aural signaling in-band as &quot;early media&quot;], =
we provide useful solutions to</FONT>
<BR><FONT SIZE=3D2>end users [providing informative responses, using =
local resources when</FONT>
<BR><FONT SIZE=3D2>possible or network resources if necessary].</FONT>
</P>

<P><FONT SIZE=3D2>&gt; On seeing a 404 response, an end UA *may* choose =
to use the information in</FONT>
<BR><FONT SIZE=3D2>&gt; the CallProgress-Info header if it is not =
capable of providing local</FONT>
<BR><FONT SIZE=3D2>&gt; annoucements, otherwise, it could render to the =
user the information</FONT>
<BR><FONT SIZE=3D2>&gt; provided in the CallProgress-Info header. How =
does this look?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>[snip]</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C086DE.D6D052D4--

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 10:20:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29548
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 10:20:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DDCBB44343; Thu, 25 Jan 2001 09:21:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 8B05944336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 09:20:51 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA08360;
	Thu, 25 Jan 2001 10:20:32 -0500 (EST)
Message-ID: <3A704440.3ACD88F6@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Igor Slepchin <ISlepchin@dynamicsoft.com>
Cc: "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
References: <B65B4F8437968F488A01A940B21982BFB9809D@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 10:20:32 -0500
Content-Transfer-Encoding: 7bit

Igor Slepchin wrote:
> 
> 1. If the UAC is gone, the UAS will get an ICMP error on the second
> retransmission of 182 and is free to drop the call after that.

This works unless the responses are directed to port 9 on some
unsuspecting target. That way, every incoming INVITE generates a bunch
of packets directed at the victim.


> 2. Whether UAS queues up messages for 10 or 100 minutes is not very
> relevant; a DOS attack just requires somewhat less resources in the first
> case than in the second. There is nothing SIP-specific in attacks that flood
> the service provider with bogus messages.
> 

Except the above multiplier.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 10:24:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29832
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 10:24:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E735A44353; Thu, 25 Jan 2001 09:25:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id C61BC44336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 09:24:06 -0500 (EST)
Received: (qmail 12056 invoked by uid 500); 25 Jan 2001 15:29:37 -0000
From: David Frascone <dave@frascone.com>
To: sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
Message-ID: <20010125092937.E11657@newman.frascone.com>
Mail-Followup-To: sip@lists.bell-labs.com
References: <B65B4F8437968F488A01A940B21982BFB9809D@DYN-EXCH-001.dynamicsoft.com> <3A704440.3ACD88F6@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A704440.3ACD88F6@cs.columbia.edu>; from hgs@cs.columbia.edu on Thu, Jan 25, 2001 at 10:20:32AM -0500
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 09:29:37 -0600

Or, simply, if the packet is forged from an address that does exist.  It will
be silently dropped, as is the way with UDP.

On Thu, Jan 25, 2001 at 10:20:32AM -0500, Henning G. Schulzrinne wrote:
> Igor Slepchin wrote:
> > 
> > 1. If the UAC is gone, the UAS will get an ICMP error on the second
> > retransmission of 182 and is free to drop the call after that.
> 
> This works unless the responses are directed to port 9 on some
> unsuspecting target. That way, every incoming INVITE generates a bunch
> of packets directed at the victim.
> 
> 
> > 2. Whether UAS queues up messages for 10 or 100 minutes is not very
> > relevant; a DOS attack just requires somewhat less resources in the first
> > case than in the second. There is nothing SIP-specific in attacks that flood
> > the service provider with bogus messages.
> > 
> 
> Except the above multiplier.
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 11:00:14 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02426
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 11:00:13 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9E51944360; Thu, 25 Jan 2001 10:00:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 4977A44336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 09:59:46 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA12163;
	Thu, 25 Jan 2001 10:59:27 -0500 (EST)
Message-ID: <3A704D5F.974B5FFC@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: David Frascone <dave@frascone.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
References: <B65B4F8437968F488A01A940B21982BFB9809D@DYN-EXCH-001.dynamicsoft.com> <3A704440.3ACD88F6@cs.columbia.edu> <20010125092937.E11657@newman.frascone.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 10:59:27 -0500
Content-Transfer-Encoding: 7bit

David Frascone wrote:
> 
> Or, simply, if the packet is forged from an address that does exist.  It will
> be silently dropped, as is the way with UDP.

Your statement is wrong. If you send a UDP packet to an unknown address,
you should get back an ICMP error ("destination unreachable"), which
causes Unix read's to fail the next time. (Java apparently doesn't have
this functionality, although this information is second-hand.)

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 11:07:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02533
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 11:07:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E2EC544376; Thu, 25 Jan 2001 10:08:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 8469244336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 10:07:24 -0500 (EST)
Received: from dynamicsoft.com (ip22.honxr1.ras.tele.dk [195.249.119.22])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA14780;
	Thu, 25 Jan 2001 11:10:03 -0500 (EST)
Message-ID: <3A704EA7.9829AD01@dynamicsoft.com>
From: Anders Kristensen <akristensen@dynamicsoft.com>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: David Frascone <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
References: <B65B4F8437968F488A01A940B21982BFB9809D@DYN-EXCH-001.dynamicsoft.com> <3A704440.3ACD88F6@cs.columbia.edu> <20010125092937.E11657@newman.frascone.com> <3A704D5F.974B5FFC@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 17:04:55 +0100
Content-Transfer-Encoding: 7bit



"Henning G. Schulzrinne" wrote:
> 
> David Frascone wrote:
> >
> > Or, simply, if the packet is forged from an address that does exist.  It will
> > be silently dropped, as is the way with UDP.
> 
> Your statement is wrong. If you send a UDP packet to an unknown address,
> you should get back an ICMP error ("destination unreachable"), which
> causes Unix read's to fail the next time. (Java apparently doesn't have
> this functionality, although this information is second-hand.)

It's supposedly in next version of the JDK to be released.

Still, I don't see what's stopping the Bad Guys from not sending ICMP
error messages. If they take being Bad seriously, that is.

--
Anders Kristensen

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 11:28:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03199
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 11:28:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7760344371; Thu, 25 Jan 2001 10:29:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id B7D2F44336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 10:28:35 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA14552;
	Thu, 25 Jan 2001 11:28:13 -0500 (EST)
Message-ID: <3A70541D.CE27A075@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Kristensen <akristensen@dynamicsoft.com>
Cc: David Frascone <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
References: <B65B4F8437968F488A01A940B21982BFB9809D@DYN-EXCH-001.dynamicsoft.com> <3A704440.3ACD88F6@cs.columbia.edu> <20010125092937.E11657@newman.frascone.com> <3A704D5F.974B5FFC@cs.columbia.edu> <3A704EA7.9829AD01@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 11:28:13 -0500
Content-Transfer-Encoding: 7bit

Anders Kristensen wrote:
> 
> "Henning G. Schulzrinne" wrote:
> >
> > David Frascone wrote:
> > >
> > > Or, simply, if the packet is forged from an address that does exist.  It will
> > > be silently dropped, as is the way with UDP.
> >
> > Your statement is wrong. If you send a UDP packet to an unknown address,
> > you should get back an ICMP error ("destination unreachable"), which
> > causes Unix read's to fail the next time. (Java apparently doesn't have
> > this functionality, although this information is second-hand.)
> 
> It's supposedly in next version of the JDK to be released.
> 
> Still, I don't see what's stopping the Bad Guys from not sending ICMP
> error messages. If they take being Bad seriously, that is.
> 

There are three separate attacks: flooding the SIP server from your real
address (nothing you can do about it, you can suppress ICMP, but you can
call the FBI or sysadmin and do router-level packet filtering if things
persist), flooding the SIP server from a bogus address (again, nothing
to be done, but at least ICMP should limit the secondary damage) and the
smurf-like attack of using a SIP server as a "force multiplier" to some
other innocent, but valid address.


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 11:40:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03573
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 11:40:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BE0B744385; Thu, 25 Jan 2001 10:41:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 2D05344336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 10:40:29 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA15572;
	Thu, 25 Jan 2001 11:43:07 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9K24P2>; Thu, 25 Jan 2001 11:36:51 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3047555@DYN-TX-EXCH-001.dynamicsoft.com>
From: Robert Sparks <rsparks@dynamicsoft.com>
To: "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>, sip@lists.bell-labs.com
Subject: ATTENTION: BAKEOFF: RE: [SIP] SIP bake-off registration
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 11:36:49 -0500


This deadline is about to pass and registration
so far has ben very light. If you are coming,
please get your registrations in.

RjS

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Thursday, January 11, 2001 2:21 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] SIP bake-off registration
> 
> 
> Please register for the 7th SIP bakeoff at
> http://www.etsi.org/bake-off/. Note that bake-off early bird
> registration closes at the end of January.
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 13:38:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05693
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 13:38:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D22A44433A; Thu, 25 Jan 2001 12:39:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from ss8mail1.ss8ott (mail.ss8.ca [209.87.228.147])
	by lists.bell-labs.com (Postfix) with ESMTP id 83D9744336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 12:38:17 -0500 (EST)
Received: from CONNIE ([192.168.1.238]) by ss8mail1.ss8ott with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id CF8WCGJV; Thu, 25 Jan 2001 13:38:29 -0500
From: "Connie Blanchard" <connie@ss8.com>
To: <sip@lists.bell-labs.com>
Message-ID: <NEBBINLBBIOMPPIEAKHGKEGKCHAA.connie@ss8.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Subject: [SIP] adding a display name in From
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 13:37:26 -0500
Content-Transfer-Encoding: 7bit

According to the SIP FAQ, Caller ID is accomplished by using the "display
name" portion of the From header. But a proxy is not supposed to modify the
From field. Does this mean that Caller ID will only be available if
initiated from the originator of the call?


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 14:22:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06497
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 14:22:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CB09144388; Thu, 25 Jan 2001 13:23:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id B602544336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 13:22:04 -0500 (EST)
Received: (qmail 13956 invoked by uid 500); 25 Jan 2001 19:27:38 -0000
From: David Frascone <dave@frascone.com>
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: sip@lists.bell-labs.com, Anders Kristensen <akristensen@dynamicsoft.com>
Subject: Re: [SIP] T2 and 182 Queued
Message-ID: <20010125132737.E12234@newman.frascone.com>
Mail-Followup-To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>,
	sip@lists.bell-labs.com,
	Anders Kristensen <akristensen@dynamicsoft.com>
References: <B65B4F8437968F488A01A940B21982BFB9809D@DYN-EXCH-001.dynamicsoft.com> <3A704440.3ACD88F6@cs.columbia.edu> <20010125092937.E11657@newman.frascone.com> <3A704D5F.974B5FFC@cs.columbia.edu> <3A704EA7.9829AD01@dynamicsoft.com> <3A70541D.CE27A075@cs.columbia.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A70541D.CE27A075@cs.columbia.edu>; from hgs@cs.columbia.edu on Thu, Jan 25, 2001 at 11:28:13AM -0500
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 13:27:37 -0600

I'm obviously not being very clear.  Let's assume that I'm forging packets
from different servers, and possibly from the discard port.  And, let's say
that I send one (1) bogus request every second.  

For each (1) bogus request, the proxy or UA will respond with (Someone 
counted this number in an earlier posting, but it will vary depending on
T1 and T2) 11 retransmissions of "User not found" or some such response.  Or,
if it is a proxy, it might do a DNS lookup, forward the request to a proxy,
and generate several more messages before it gets back to sending it's
11 retransmitted 4xx responses.

So, the DoS problem isn't a simple flood, it's the number of messages and
amount of network traffic  that can be generated from one bogus packet.

Now, imagine what happens if instead of sending one a second, the "Bad Guy"
decides to flood them.

*That* is the vunerability that *I'm* talking about.


-Dave

On Thu, Jan 25, 2001 at 11:28:13AM -0500, Henning G. Schulzrinne wrote:
> Anders Kristensen wrote:
> > 
> > "Henning G. Schulzrinne" wrote:
> > >
> > > David Frascone wrote:
> > > >
> > > > Or, simply, if the packet is forged from an address that does exist.  It will
> > > > be silently dropped, as is the way with UDP.
> > >
> > > Your statement is wrong. If you send a UDP packet to an unknown address,
> > > you should get back an ICMP error ("destination unreachable"), which
> > > causes Unix read's to fail the next time. (Java apparently doesn't have
> > > this functionality, although this information is second-hand.)
> > 
> > It's supposedly in next version of the JDK to be released.
> > 
> > Still, I don't see what's stopping the Bad Guys from not sending ICMP
> > error messages. If they take being Bad seriously, that is.
> > 
> 
> There are three separate attacks: flooding the SIP server from your real
> address (nothing you can do about it, you can suppress ICMP, but you can
> call the FBI or sysadmin and do router-level packet filtering if things
> persist), flooding the SIP server from a bogus address (again, nothing
> to be done, but at least ICMP should limit the secondary damage) and the
> smurf-like attack of using a SIP server as a "force multiplier" to some
> other innocent, but valid address.
> 
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 14:49:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07398
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 14:49:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 62FFE44399; Thu, 25 Jan 2001 13:50:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id E3B4D44399
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 13:49:45 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08659;
	Thu, 25 Jan 2001 11:49:19 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27136;
	Thu, 25 Jan 2001 11:49:18 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA16640;
	Thu, 25 Jan 2001 11:49:01 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: RE: [SIP] T2 and 182 Queued
To: Igor Slepchin <ISlepchin@dynamicsoft.com>
Cc: "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com,
        smb@research.att.com
Message-ID: <Roam.SIMC.2.0.6.980452141.10111.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 11:49:01 -0800 (PST)

[CC'ing Steve Bellovin]

> 1. If the UAC is gone, the UAS will get an ICMP error on the second
> retransmission of 182 and is free to drop the call after that.
sigh. only if an ICMP error is received, and that is NOT guaranteed.

> 2. Whether UAS queues up messages for 10 or 100 minutes is not very
> relevant; 
correct.

> a DOS attack just requires somewhat less resources in the first
> case than in the second. There is nothing SIP-specific in attacks that flood
> the service provider with bogus messages.

hmm.... I respectfully disagree. As I hope you probably know, carriers and
companies with web infrastructure have spent lots of time trying to figure out
how to deal with DoS attacks, such as the TCP SYN attack. Router and operating
system vendors have spent lots of time and energy in fixing code to prevent
these. Now you are stating that it is OK to ignore a new DoS attack, and worry
about it later when it affects deployed services.

I've heard crypto as the solution. Again, if a global PKI existed, we wouldn't
be dealing with ANY DoS attacks, because all IP flows would be secured. But we
all know that we are far from there...

The IESG, and some trusted security advisors, have requested that WGs be more
proactive in identiying, and fixing, protocols that are suceptible to DoS
attacks. I know that there are ways around the problem identified, so perhaps
the WG should be more active in fixing these. Mandating TCP is an obvious
choice, but perhaps there are ways to fix UDP as well?

What am I missing?

PatC

> 1. If the UAC is gone, the UAS will get an ICMP error on the second
> retransmission of 182 and is free to drop the call after that.
> 2. Whether UAS queues up messages for 10 or 100 minutes is not very
> relevant; a DOS attack just requires somewhat less resources in the first
> case than in the second. There is nothing SIP-specific in attacks that flood
> the service provider with bogus messages.
> 
> ---
> Igor Slepchin
> 
> 
> > -----Original Message-----
> > From: David Frascone [mailto:dave@frascone.com]
> > Sent: Wednesday, January 24, 2001 1:11 PM
> > To: sip@lists.bell-labs.com
> > Subject: Re: [SIP] T2 and 182 Queued
> > 
> > 
> > This bounced when Pat tried to send it, so I'm forwarding it.  
> > 
> > ----- Forwarded message from Pat Calhoun <pcalhoun@eng.sun.com> -----
> > 
> > Date: Wed, 24 Jan 2001 09:15:44 -0800 (PST)
> > From: Pat Calhoun <pcalhoun@eng.sun.com>
> > Reply-To: Pat Calhoun <pcalhoun@eng.sun.com>
> > Subject: Re: [SIP] T2 and 182 Queued
> > To: David Frascone <dave@frascone.com>
> > Cc: sip@lists.bell-labs.com
> > Message-ID: <Roam.SIMC.2.0.6.980356544.32567.pcalhoun@nasnfs>
> > 
> > > 
> > > Everything is happy above.  But, what about this:
> > > 
> > > 
> > >     UA1                             UA2
> > >      |                               |
> > >      |             INVITE            |
> > >      |------------------------------>|
> > >      |                               |
> > >      |      182 Queue Position 120   |
> > >      |<------------------------------|
> > >      |                               |
> > >    Here, the UA1 pulls the plug on his computer, drives 
> > into a tunnel,
> > >    has a power outage, ISP drops the connection, etc.  No 
> > cancel, just
> > >    vanishes.
> > > 
> > >      |      182 Queue Position 110   |
> > >      |<------------------------------|
> > >      |                               |
> > >      |      182 Queue Position 100   |
> > >      |<------------------------------|
> > >      |                               |
> > >      |      182 Queue Position 1     |
> > >      |<------------------------------|
> > >      |                               |
> > >      |            200 OK F4          |
> > >      |<------------------------------|
> > >      |                               |
> > >      |   UA2 Timer FINALLY times out |
> > >      |                               |
> > >     UA1                             UA2
> > > 
> > > 
> > > So, the UA keeps him in the queue, spitting out UDP packets 
> > for a LONG
> > > time, without ever knowing that UA1 is no longer on the 
> > network.  So, if
> > > T2 *is* used, the timeout is way too short.  If T2 is NOT 
> > used, then there
> > > is an big waste of retransmissions for queued calls.  
> > Perhaps PRACK should be
> > > required for long queue times?  There might even be a DOS 
> > attack by forging
> > > tons of INVITES to a full queue.
> > > 
> > > Now do you see the problem?  
> > 
> > Putting aside the obvious case of wasted resources, I think 
> > that the potential
> > for denial of service attacks is THE reason why this is 
> > broken. Imagine
> > competitor A issuing a UDP based IP address spoofing attack 
> > on competitor B,
> > filling up their call queues. With the number of calls, the 
> > queue will quickly
> > fill up, so I believe it is a MUST that the 182 messages be 
> > ack'ed, to reduce
> > the queue size. This should be a MUST, regardless of the wait time.
> > 
> > I think that proofing against DoS attacks should be a high 
> > priority item for
> > the WG.
> > 
> > PatC
> > 
> > 
> > ----- End forwarded message -----
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> > 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.



----- End forwarded message -----


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 14:51:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07430
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 14:51:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E49F8443AA; Thu, 25 Jan 2001 13:52:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id 1F2BF44336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 13:51:33 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09980;
	Thu, 25 Jan 2001 11:51:14 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27609;
	Thu, 25 Jan 2001 11:51:13 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA16672;
	Thu, 25 Jan 2001 11:51:11 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: Re: [SIP] T2 and 182 Queued
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: Anders Kristensen <akristensen@dynamicsoft.com>,
        David Frascone <dave@frascone.com>, sip@lists.bell-labs.com
Message-ID: <Roam.SIMC.2.0.6.980452272.8217.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 11:51:12 -0800 (PST)

> There are three separate attacks: flooding the SIP server from your real
> address (nothing you can do about it, you can suppress ICMP, but you can
> call the FBI or sysadmin and do router-level packet filtering if things
> persist), flooding the SIP server from a bogus address (again, nothing
> to be done, but at least ICMP should limit the secondary damage) and the
> smurf-like attack of using a SIP server as a "force multiplier" to some
> other innocent, but valid address.

and TCP solves the last two.

btw, imagine an attack where a malicious user issues SIP invites from bogus
addresses, but routable addresses, with a source port of 7 (echo port).

I'd like to see a SIP server withstand one of those attacks.

PatC


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 15:29:15 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08222
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 15:29:14 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BAC08443BD; Thu, 25 Jan 2001 14:27:09 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 34A224439B
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 14:26:18 -0500 (EST)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0G7Q005KMJDGEZ@firewall.mcit.com> for sip@lists.bell-labs.com;
 Thu, 25 Jan 2001 20:24:53 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0G7Q00H01JDA22@dgismtp01.wcomnet.com>;
 Thu, 25 Jan 2001 20:24:52 +0000 (GMT)
Received: from Steveb1 ([166.35.224.41])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0G7Q00G3WJD51R@dgismtp01.wcomnet.com>; Thu,
 25 Jan 2001 20:24:42 +0000 (GMT)
From: "Christopher A. Martin" <christopher.a.martin@wcom.com>
Subject: RE: [SIP] T2 and 182 Queued
In-reply-to: <Roam.SIMC.2.0.6.980452272.8217.pcalhoun@nasnfs>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Reply-To: christopher.a.martin@wcom.com
Message-id: <000d01c0870c$bf543ca0$6401010a@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 14:23:57 -0600
Content-Transfer-Encoding: 7bit

Patrice,
RE: your comment " I'd like to see a SIP server withstand one of those
attacks.". I believe that we have firewalls to provide the single point of
failure in the event of DoS attacks, among other things. Yes you harden a
server to a point, but the firewalls along the path should provide the
protection against DoS. When I speak of firewalls I mean the architecture
that consists of the routers, intrusion detection systems, and the actual
"firewall" device. Even in a public network you should have a firewall in
place to filter before it gets to the public server.

I believe that the methods and policies used to protect against denial of
service attacks should be implemented at the firewall.

If we implement it at the server level there is the possibility to add
latency in processing times on the server itself.

I also believe that SIP awareness needs to be implemented on firewalls and
intrusion detection systems.

A global PKI would seem to be a natural progression if implemented at the
firewall level, when speaking of server complexes, and one that I would like
to see pursued. Once authenticated to the firewall one could "assume" a
minimal level of end-to-end security/accountability or "trust" in relation
to SIP communications.

Along the same lines, has any further work been done with the draft, or are
there similar drafts, draft-ietf-mmusic-sip-sec-00.txt by P. Kirstein, G.
Montasser-Kohsari, and E. Whelan.

If there is another list covering this I would like to find out so that I
can join it.

I am glad that this is being addressed now and would like to encourage this
discussion to continue, if not here then in another forum along these lines.

That's just my humble opinion.

Thanks in advance for any information on the above draft,

Christopher A. Martin
Security Integration Engineer, IPCOMM
MCI/WorldCom
972-729-4569

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Patrice Calhoun
> Sent: Thursday, January 25, 2001 1:51 PM
> To: Henning G. Schulzrinne
> Cc: Anders Kristensen; David Frascone; sip@lists.bell-labs.com
> Subject: Re: [SIP] T2 and 182 Queued
>
>
> > There are three separate attacks: flooding the SIP server
> from your real
> > address (nothing you can do about it, you can suppress
> ICMP, but you can
> > call the FBI or sysadmin and do router-level packet
> filtering if things
> > persist), flooding the SIP server from a bogus address
> (again, nothing
> > to be done, but at least ICMP should limit the secondary
> damage) and the
> > smurf-like attack of using a SIP server as a "force
> multiplier" to some
> > other innocent, but valid address.
>
> and TCP solves the last two.
>
> btw, imagine an attack where a malicious user issues SIP
> invites from bogus
> addresses, but routable addresses, with a source port of 7
> (echo port).
>
> I'd like to see a SIP server withstand one of those attacks.
>
> PatC
>
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
>


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 15:36:59 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08313
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 15:36:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1AC3F443D1; Thu, 25 Jan 2001 14:37:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16])
	by lists.bell-labs.com (Postfix) with ESMTP id BE4A3443CC
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 14:36:39 -0500 (EST)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0G7Q0007PJR22C@firewall.mcit.com> for sip@lists.bell-labs.com;
 Thu, 25 Jan 2001 20:33:02 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0G7Q00M01JR01Z@dgismtp01.wcomnet.com>;
 Thu, 25 Jan 2001 20:33:02 +0000 (GMT)
Received: from Steveb1 ([166.35.224.41])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0G7Q00L0UJQMS4@dgismtp01.wcomnet.com>; Thu,
 25 Jan 2001 20:32:46 +0000 (GMT)
From: "Christopher A. Martin" <christopher.a.martin@wcom.com>
Subject: RE: [SIP] T2 and 182 Queued
In-reply-to: <Roam.SIMC.2.0.6.980452272.8217.pcalhoun@nasnfs>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Reply-To: christopher.a.martin@wcom.com
Message-id: <000e01c0870d$dff25860$6401010a@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 14:32:01 -0600
Content-Transfer-Encoding: 7bit

You bring up good points. Here are some other areas of concern that will
need to be addressed by firewall vendors regarding topology and information
disclosure.

There are many issues to consider besides DoS attacks with SIP. With the
potential for internal topology to be disclosed in Record-Route, Via, and
other fields scanning tools based on SIP could easily be created to gather
the information needed to make directed attacks/intrusions on internal
networks.

A PKI could provide a form of accountability that would be necessary to
insure confidence in SIP services, as well as quicker response to tracking
DoS attacks by using the authentication as a starting point. Perhaps even at
the certificate level.

Just something else to ponder,
Christopher A. Martin
Security Integration Engineer, IPCOMM
MCI/WorldCom
972-729-4569

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Patrice Calhoun
> Sent: Thursday, January 25, 2001 1:51 PM
> To: Henning G. Schulzrinne
> Cc: Anders Kristensen; David Frascone; sip@lists.bell-labs.com
> Subject: Re: [SIP] T2 and 182 Queued
>
>
> > There are three separate attacks: flooding the SIP server
> from your real
> > address (nothing you can do about it, you can suppress
> ICMP, but you can
> > call the FBI or sysadmin and do router-level packet
> filtering if things
> > persist), flooding the SIP server from a bogus address
> (again, nothing
> > to be done, but at least ICMP should limit the secondary
> damage) and the
> > smurf-like attack of using a SIP server as a "force
> multiplier" to some
> > other innocent, but valid address.
>
> and TCP solves the last two.
>
> btw, imagine an attack where a malicious user issues SIP
> invites from bogus
> addresses, but routable addresses, with a source port of 7
> (echo port).
>
> I'd like to see a SIP server withstand one of those attacks.
>
> PatC
>
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
>


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 15:43:10 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08385
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 15:43:10 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D93EA443D7; Thu, 25 Jan 2001 14:41:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 92E7144336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 14:40:18 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14530;
	Thu, 25 Jan 2001 12:39:56 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19457;
	Thu, 25 Jan 2001 12:39:29 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA17489;
	Thu, 25 Jan 2001 12:39:08 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: RE: [SIP] T2 and 182 Queued
To: christopher.a.martin@wcom.com
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" <000d01c0870c$bf543ca0$6401010a@mcit.com>
Message-ID: <Roam.SIMC.2.0.6.980455149.5856.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 12:39:09 -0800 (PST)

> Patrice,
> RE: your comment " I'd like to see a SIP server withstand one of those
> attacks.". I believe that we have firewalls to provide the single point of
> failure in the event of DoS attacks, among other things. Yes you harden a
> server to a point, but the firewalls along the path should provide the
> protection against DoS. When I speak of firewalls I mean the architecture
> that consists of the routers, intrusion detection systems, and the actual
> "firewall" device. Even in a public network you should have a firewall in
> place to filter before it gets to the public server.

Of course. fixes have been done to minimize SYN attacks, but building a
protocol with a specific architecture in mind is a bad decision, IMHO. Many
people will deploy SIP servers, and perhaps not have firewalls.

(in any case, it sounds so much simpler to fix the protocol than to require
firewalls)

> 
> I believe that the methods and policies used to protect against denial of
> service attacks should be implemented at the firewall.
> 
> If we implement it at the server level there is the possibility to add
> latency in processing times on the server itself.

sure, unless you mandate TCP, which already fixes these problems. Perhaps
there are other ways, and I wouldn't be against looking at different solutions.
 > 
> I also believe that SIP awareness needs to be implemented on firewalls and
> intrusion detection systems.

see above.

> 
> A global PKI would seem to be a natural progression if implemented at the
> firewall level, when speaking of server complexes, and one that I would like
> to see pursued. Once authenticated to the firewall one could "assume" a
> minimal level of end-to-end security/accountability or "trust" in relation
> to SIP communications.

Putting a cert on the SIP server is a quarter (or even less) of the problem.
The issue then is to distribute certificates with ANYONE that will communicate
with your SIP server (and I DO mean anyone!). If my grand-mother wants to call
you, must she first go to her favorite PKI vendor and get a signed cert?

> 
> Along the same lines, has any further work been done with the draft, or are
> there similar drafts, draft-ietf-mmusic-sip-sec-00.txt by P. Kirstein, G.
> Montasser-Kohsari, and E. Whelan.
> 
> If there is another list covering this I would like to find out so that I
> can join it.

ditto.

PatC


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 15:50:38 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08509
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 15:50:37 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CF68D443B7; Thu, 25 Jan 2001 14:47:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by lists.bell-labs.com (Postfix) with ESMTP id CBA13443C8
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 14:46:43 -0500 (EST)
Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16])
	by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA08834;
	Thu, 25 Jan 2001 15:46:09 -0500 (EST)
Received: from cisco.com (rtp-ptdxdm1.cisco.com [64.102.17.217])
	by dingdong.cisco.com (Mirapoint)
	with ESMTP id AAP01446 (AUTH byerly);
	Thu, 25 Jan 2001 15:46:30 -0500 (EST)
Message-ID: <3A7090A4.481E6663@cisco.com>
From: Bryan Byerly <byerly@cisco.com>
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Thomas <mat@cisco.com>
Cc: Venkatesh Venkataramanan <Venkatesh.Venkataramanan@sylantro.com>,
        sip@lists.bell-labs.com, byerly@cisco.com
Subject: Re: [SIP] Announcements in SIP
References: <79FEAA5FABA7D411BF580001023D1BBD26D7E8@mailserver.sylantro.com>
		<3A6C8CEA.E77B1FBC@cisco.com> <14959.12178.83257.947866@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 15:46:28 -0500
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:

> Bryan Byerly writes:
>  > The approach using a Contact in the response would also work for smart
>  > UAs.
>  >
>  > A              Po             Pt           AnnServer
>  > |              |              |                |
>  > |--INV Bob@Po->|              |                |
>  > |              |--INV Bob@Pt->|                |
>  > |              |              |                |
>  > |              |<-404---------|                |
>  > |              |              |                |
>  > |<-404---------|              |                |
>  > |  Contact: AnnServer         |                |
>  > |              |              |                |
>  > |--INV AnnServer------------------------------>|
>  > |              |              |                |
>  > |<-183/200-------------------------------------|
>  > |              |              |                |
>  > |<="The URL you have dialed B...O...B at Pt is=|
>  > |   unrouteable, please check the URL or       |
>  > |   contact your system admin for assistance"  |
>  >
>  >
>  >
>  > However,
>  > a) this doesn't provide an announcements solution for dumb UAs
>
>    How so? It's the announcement server that has the
>    smarts, right?

UAs which are RFC2543 compliant but not rfc2543bis-02 (including clients
supporting minimal implementations of SIP defined by RFC2543 aand
rfc2543bis-02) (i.e. dumb UAs) do not support the following behavior added in
the rfc2543bis-02 draft:
4xx, 5xx, 6xx:
The Contact response-header field can be used with a 4xx, 5xx, or 6xx
response to indicate the location where additional information about the
error can be found.

That being said, this is definitely a solution that could be used with
RFC2543bis-02 compliant UAs.

>  > b) I doubt a smart UA would even need an AnnServer contact.  Since he's
>  > smart, he would either 1) be able to generate annoucements locally or
>  > 2) know the FQDN/IP address of the AnnServer directly.  I'm not aware
>  > that smart UAs need any proxy assist. (Although, they would need to be
>  > able to turn off proxy assist).
>
>    It's not like the smart UA would need to be
>    *forced* to use the contact header, right?
>    If it thinks it can put on a better side show
>    than the announcement server, nothing's
>    stopping it, right?

Agreed.

>  >
>  > In the proposal above, how would the Announcement server know to say
>  > "B...O...B"?
>
>    contact: sip:ann@foo.com?luser=bob
>
>    or some such?

So, we could discuss such an approach.  However, we'd need additional
URL syntax for reason codes, we'd need to talk about how this works when
there are multiple diversions and with private numbering plans.  And, we'd
need an I-D that explains what URI parameters to use so that different
vendor's implementations of user agents, gateways, proxies, and anoucements
servers would be interoperable.

My guess is that we'd end up to a functionally equivalent solution to using
the Diversion header.  But, I'm open to discussing it.

>  > One solution would be for the Annoucement server to examine the
>  > Diversion header (draft-levy-sip-diversion-01.txt).  The Diversion
>  > header provides the necessary supplemental information to the
>  > announcement server.  Since the Diversion header is already needed for
>  > voicemail servers, I think it is a good candidate for usage here.
>
>    The problem with the diversion header is that
>    my UA never got a chance to, oh say, have my
>    UA brew me another cup of coffee while I'm
>    camping on Bob to become available. Instead,
>    the *proxy* decided that for me, and as a
>    result I get no coffee to pacify me.
>
>             Mike

A Diversion header provides supplemental information to the ultimately called
UA, regardless of whether the diversion was implemented by a user agent or
proxy.  The draft does not give preference to either method.. that's a policy
decision.  If that's not clear from the Diversion I-D, then I'd appreciate
your pointing out the confusing sections so I may fix them.

thanks for your help,
Bryan

Bryan J. Byerly
byerly@cisco.com



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 16:01:08 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08689
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 16:01:07 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F2F80443E8; Thu, 25 Jan 2001 14:56:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id C237D443E7
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 14:55:42 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA05634;
	Thu, 25 Jan 2001 15:54:59 -0500 (EST)
Message-ID: <3A7092A2.21DD6514@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: christopher.a.martin@wcom.com,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
References: <Roam.SIMC.2.0.6.980455149.5856.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 15:54:58 -0500
Content-Transfer-Encoding: 7bit

Patrice Calhoun wrote:
> 

> (in any case, it sounds so much simpler to fix the protocol than to require
> firewalls)

Suggestions are welcome, but I would guess that any such fix will
increase the message complexity of the non-DoS case and thus reduce
overall throughput. For example, use of TCP and IPsec definitely will,
due to the extra round-trip times and TCP-level messages.

Thus, with a datagram protocol it is probably provably impossible to
prevent flooding of the server, SIP or otherwise. (DNS, for example, has
the same issue, as does any other query-response protocol.) The only
means to avoid the amplifier effect is to require a handshake (IPsec,
TCP, whatever) before sending more than one message.

All TCP SYN flood mechanisms simply minimize the amount of state that is
committed on the server prior to completion of the handshake.
Fortunately, SIP authentication will minimize the amount of state, if
not computation.

For SIP, the standard (basic or digest) authentication provides such a
handshake. If somebody attacks you with a non-authenticated request,
reject immediately with 401/407. Don't send 100 or (if under attack)
additional 401s. A non-malicious INVITEr will retransmit the INVITE if
the 401 got lost. This solves the multiplier problem.

Digest already echoes back parts of the challenge, so this is as good as
the standard IPsec anti-clogging mechanism. We don't seem to know
anything better at this point, SIP or otherwise.

Basic is of dubious merit, but probably the CPU effort is sufficiently
low not to matter. (The larger expense is likely to be the lookup of the
name in larger installations, not the hash comparison.)


> sure, unless you mandate TCP, which already fixes these problems. Perhaps
> there are other ways, and I wouldn't be against looking at different solutions.

TCP does not fix the problem in any magic way. See above.

>  >
> > I also believe that SIP awareness needs to be implemented on firewalls and
> > intrusion detection systems.

> Putting a cert on the SIP server is a quarter (or even less) of the problem.
> The issue then is to distribute certificates with ANYONE that will communicate
> with your SIP server (and I DO mean anyone!). If my grand-mother wants to call
> you, must she first go to her favorite PKI vendor and get a signed cert?

No, but see our approach in sipd for a workable, albeit less than 100%
secure mechanism of authentication of "first-time callers".



-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 16:08:46 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08814
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 16:08:46 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9F657443C5; Thu, 25 Jan 2001 15:07:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by lists.bell-labs.com (Postfix) with ESMTP id 12EAF443B5
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 15:06:55 -0500 (EST)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0G7Q0048LLA8CN@firewall.mcit.com> for sip@lists.bell-labs.com;
 Thu, 25 Jan 2001 21:06:08 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0G7Q00I01L9L4N@dgismtp01.wcomnet.com>;
 Thu, 25 Jan 2001 21:05:55 +0000 (GMT)
Received: from Steveb1 ([166.35.224.41])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0G7Q00H3GL9FNQ@dgismtp01.wcomnet.com>; Thu,
 25 Jan 2001 21:05:39 +0000 (GMT)
From: "Christopher A. Martin" <christopher.a.martin@wcom.com>
Subject: RE: [SIP] T2 and 182 Queued
In-reply-to: <Roam.SIMC.2.0.6.980455149.5856.pcalhoun@nasnfs>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>
Cc: "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Reply-To: christopher.a.martin@wcom.com
Message-id: <001501c08712$773e3320$6401010a@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 15:04:51 -0600
Content-Transfer-Encoding: 7bit

This is just an assumption on my part, but as SIP gets implemented as a
service by many providers couldn't the user receive a cert as part of the
sign up process, using the providers public certificate server.

With this type of scenario the provideer would have information on file
about the user which is where accountability would come in. I am in no way
an authority on certificate authorities, this is just an thought on my part.

Chris

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Patrice Calhoun
> Sent: Thursday, January 25, 2001 2:39 PM
> To: christopher.a.martin@wcom.com
> Cc: 'Patrice Calhoun'; 'Henning G. Schulzrinne'; 'Anders Kristensen';
> 'David Frascone'; sip@lists.bell-labs.com
> Subject: RE: [SIP] T2 and 182 Queued
>
>
> > Patrice,
> > RE: your comment " I'd like to see a SIP server withstand
> one of those
> > attacks.". I believe that we have firewalls to provide the
> single point of
> > failure in the event of DoS attacks, among other things.
> Yes you harden a
> > server to a point, but the firewalls along the path should
> provide the
> > protection against DoS. When I speak of firewalls I mean
> the architecture
> > that consists of the routers, intrusion detection systems,
> and the actual
> > "firewall" device. Even in a public network you should have
> a firewall in
> > place to filter before it gets to the public server.
>
> Of course. fixes have been done to minimize SYN attacks, but
> building a
> protocol with a specific architecture in mind is a bad
> decision, IMHO. Many
> people will deploy SIP servers, and perhaps not have firewalls.
>
> (in any case, it sounds so much simpler to fix the protocol
> than to require
> firewalls)
>
> >
> > I believe that the methods and policies used to protect
> against denial of
> > service attacks should be implemented at the firewall.
> >
> > If we implement it at the server level there is the
> possibility to add
> > latency in processing times on the server itself.
>
> sure, unless you mandate TCP, which already fixes these
> problems. Perhaps
> there are other ways, and I wouldn't be against looking at
> different solutions.
>  >
> > I also believe that SIP awareness needs to be implemented
> on firewalls and
> > intrusion detection systems.
>
> see above.
>
> >
> > A global PKI would seem to be a natural progression if
> implemented at the
> > firewall level, when speaking of server complexes, and one
> that I would like
> > to see pursued. Once authenticated to the firewall one
> could "assume" a
> > minimal level of end-to-end security/accountability or
> "trust" in relation
> > to SIP communications.
>
> Putting a cert on the SIP server is a quarter (or even less)
> of the problem.
> The issue then is to distribute certificates with ANYONE that
> will communicate
> with your SIP server (and I DO mean anyone!). If my
> grand-mother wants to call
> you, must she first go to her favorite PKI vendor and get a
> signed cert?
>
> >
> > Along the same lines, has any further work been done with
> the draft, or are
> > there similar drafts, draft-ietf-mmusic-sip-sec-00.txt by
> P. Kirstein, G.
> > Montasser-Kohsari, and E. Whelan.
> >
> > If there is another list covering this I would like to find
> out so that I
> > can join it.
>
> ditto.
>
> PatC
>
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
>


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 16:11:59 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08882
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 16:11:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 31905443E5; Thu, 25 Jan 2001 15:08:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by lists.bell-labs.com (Postfix) with ESMTP id A2254443B5
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 15:07:27 -0500 (EST)
Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16])
	by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA10149;
	Thu, 25 Jan 2001 16:06:53 -0500 (EST)
Received: from cisco.com (rtp-ptdxdm1.cisco.com [64.102.17.217])
	by dingdong.cisco.com (Mirapoint)
	with ESMTP id AAP02199 (AUTH byerly);
	Thu, 25 Jan 2001 16:07:13 -0500 (EST)
Message-ID: <3A70957E.C21C8848@cisco.com>
From: Bryan Byerly <byerly@cisco.com>
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Venkatesh Venkataramanan <Venkatesh.Venkataramanan@sylantro.com>
Cc: sip@lists.bell-labs.com, byerly@cisco.com
Subject: Re: FW: [SIP] Announcements in SIP
References: <79FEAA5FABA7D411BF580001023D1BBD26E215@mailserver.sylantro.com>
Content-Type: multipart/alternative;
 boundary="------------638E88A656E93C34FA039F90"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 16:07:11 -0500


--------------638E88A656E93C34FA039F90
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Venkatesh Venkataramanan wrote:

>  Hi.Thought I had forwarded this email back to you, but haven't heard
> from you since. Is this a viable suggestion??
>
> Sorry for my slow response.  I was on jury duty the past two days.
> I'm back now.
>  Cheers!
> -----Original Message-----
> From: Venkatesh Venkataramanan
> Sent: Monday, January 22, 2001 1:31 PM
> To: 'Bryan Byerly'; Venkatesh Venkataramanan; sip@lists.bell-labs.com
> Subject: RE: [SIP] Announcements in SIP
>
> I think usage of the diversion-info here is a nice way to notify the
> annc-server. For over-coming the problem with dumb UA's may be we can
> use something similar to Alert-Info extension that was proposed to
> provide alternate information as regards call progress, infact I
> propose to rename Alert-Info to CallProgress-Info so that this header
> may be used to report call progress/status of any calls, not just
> alerting. What do u think of this ? This header could provide
> inforamation for playing the particular annc.
>
> Can you point me to the I-D or discussion thread that describes
> Alert-Info?  I'm afraid I've missed it.
>
> So to summarize my thoughts a 404 response shall contain a
> CallProgress-Info which provides information to dumb UA's as regards
> annc. Smart UA's can ignore this information and provide local annc.
> Does this sound reasonable? Any repercussions??Venkatesh-----Original
> Message-----
> From: Bryan Byerly [mailto:byerly@cisco.com]
> Sent: Monday, January 22, 2001 11:42 AM
> To: Venkatesh Venkataramanan; sip@lists.bell-labs.com
> Cc: byerly@cisco.com
> Subject: Re: [SIP] Announcements in SIP
>
>
>      Venkatesh Venkataramanan wrote:
>
>     > Alternate Suggestion:If I understand 404 response right,
>     > all that the proxies do today is to forward them down to
>     > the UA. So, instead of making the proxy either translate
>     > the 404 to a 302 or implementing call forwarding to an
>     > annc server on receipt of a 404, I was thinking more on
>     > the lines of just forwarding the 404 response down to the
>     > UA, very much like today, except that the proxy adds a
>     > Contact: AnncServer_URL. A smart UA (that can provide
>     > local annc would do so, seeing the 404) where as a UA that
>     > doesn't have any local playback capabilities would contact
>     > the Contact: URL to provide local announcements. So, no
>     > extensions involved (except the work of adding a Contact
>     > in a 404 response).Any thoughts on this suggestion?
>
>
>      The approach using a Contact in the response would also work
>      for smart UAs.
>
>      A              Po             Pt           AnnServer
>      |              |              |                |
>      |--INV Bob@Po->|              |                |
>      |              |--INV Bob@Pt->|                |
>      |              |              |                |
>      |              |<-404---------|                |
>      |              |              |                |
>      |<-404---------|              |                |
>      |  Contact: AnnServer         |                |
>      |              |              |                |
>      |--INV AnnServer------------------------------>|
>      |              |              |                |
>      |<-183/200-------------------------------------|
>      |              |              |                |
>      |<="The URL you have dialed B...O...B at Pt is=|
>      |   unrouteable, please check the URL or       |
>      |   contact your system admin for assistance"  |
>
>
>
>      However,
>      a) this doesn't provide an announcements solution for dumb
>      UAs
>      b) I doubt a smart UA would even need an AnnServer contact.
>      Since he's smart, he would either 1) be able to generate
>      annoucements locally or 2) know the FQDN/IP address of the
>      AnnServer directly.  I'm not aware that smart UAs need any
>      proxy assist. (Although, they would need to be able to turn
>      off proxy assist).
>
>      In the proposal above, how would the Announcement server
>      know to say "B...O...B"?
>      One solution would be for the Annoucement server to examine
>      the Diversion header (draft-levy-sip-diversion-01.txt).  The
>      Diversion header provides the necessary supplemental
>      information to the announcement server.  Since the Diversion
>      header is already needed for voicemail servers, I think it
>      is a good candidate for usage here.
>
>      What do you think?
>
>      thanks,
>      Bryan
>
>      Bryan J. Byerly
>      byerly@cisco.com
>
>
>     >      -----Original Message-----
>     >      From: Bryan Byerly [mailto:byerly@cisco.com]
>     >      Sent: Monday, January 22, 2001 8:54 AM
>     >      To: sip@lists.bell-labs.com
>     >      Cc: byerly@cisco.com
>     >      Subject: [SIP] Announcements in SIP
>     >      Hi guys,
>     >
>     >      I'd like to solicit ideas/consensus w/r/t
>     >      announcements in SIP.
>     >
>     >      For this thread of discussion, we're talking
>     >      about announcements which are played when an
>     >      error occurred during call setup.  For instance,
>     >      on 404, a message could be played "The URL you
>     >      have dialed B...O...B. is not in service, please
>     >      check the URL or dial the operator for
>     >      assistance".
>     >
>     >      There are at least two desired behaviors w/r/t
>     >      annoucements:
>     >      Desired behavior 1: There should be a mechanism
>     >      so that local annoucements override network
>     >      annoucements.
>     >      Desired behavior 2: There should be a mechanism
>     >      so that announcements are not billable.
>     >
>     >      Like call forwarding features in SIP, there are
>     >      implementable solutions to play annoucements
>     >      using user agents or proxies.
>     >
>     >      In the diagrams below, A, B, and C are user
>     >      agents, Po is an originating proxy and Pt is a
>     >      terminating proxy.
>     >
>     >      User agent: Event based local announcement
>     >      A                 Po             Pt
>     >      |                  |              |
>     >      |--INV Bob@B------>|              |
>     >      |                  |              |
>     >      |<-404-------------|              |
>     >      |                  |              |
>     >      A generates
>     >      local audio
>     >      indicating
>     >      "The URL you have dialed B...O...B is not in
>     >      service, please check the
>     >       URL or dial the operator for assistance."
>     >
>     >
>     >      Proxy: Event based call diversion (recursive)
>     >      A                  Po             Pt
>     >      Announcement
>     >
>     >      Server
>     >      |                  |              |
>     >      |
>     >      |--INV Bob@B------>|              |
>     >      |
>     >      |                  |--INV Bob@B-->|
>     >      |
>     >      |                  |<-404---------|
>     >      |
>     >      |            proxy implements     |
>     >      |
>     >      |            call forward on 404  |
>     >      |
>     >      |                  |--INV
>     >      AnnServer------------>|
>     >      |                  |  Diversion: Bob@B
>     >      |
>     >      |                  |              |
>     >      |
>     >
>     >      <-200------------------------------------------|
>     >
>     >      |<==="The URL you have dialed B...O...B is
>     >      not==|
>     >      |     in service, please check the URL or dial
>     >      |
>     >      |     the operator for assistance"
>     >
>     >
>     >      Both approaches are viable and there are
>     >      advantages/disadvantages to each.  If all user
>     >      agents supported local generation of
>     >      announcements, then an event based call
>     >      diversion solution may not be needed.  However,
>     >      in today's world, many user agent
>     >      implementations do not have support for
>     >      generating local announcements.
>     >
>     >      Advantages for "event based local announcements"
>     >
>     >      a) requires no network bandwidth
>     >      b) requires no annoucements server
>     >
>     >      Disadvantages for "event based local
>     >      announcements"
>     >      a) Not all SIP user agents support locally
>     >      generated announcements
>     >      b) provisioning issues for large-scale
>     >      deployments. (i.e. If desirable, how would a
>     >      network admin configure multi-vendor SIP phones
>     >      in his net with certain announcements).
>     >
>     >      Advantages for "event based call diversion"
>     >      a) Provides annoucement support in multi-vendor
>     >      networks across all SIP user agents
>     >      b) Provisioning is centralized at proxy and
>     >      announcement server
>     >
>     >      Disadvantages for "event based call diversion"
>     >      a) requires network bandwidth to play
>     >      annoucements
>     >      b) requires presence of an announcements server
>     >
>     >      I'm not interested in a holy war of which to
>     >      use.  Each solution will be appropriate for
>     >      certain network deployments.  There will soon be
>     >      implementations of event based local
>     >      annoucements and event based call diversion.
>     >      The more important issue is to define a
>     >      mechanism to get desired feature interaction.
>     >
>     >
>     >
>     >      Desired behavior 1: There should be a mechanism
>     >      so that local annoucements override network
>     >      annoucements.
>     >
>     >      I would like the behavior that locally generated
>     >      annoucements take precendence over proxy event
>     >      based call diversion.  In other words, given a
>     >      UA that is configured to play announcement X and
>     >      proxy that is configured to divert to an
>     >      announcement server to play message Y, I want X
>     >      to be played.  i.e. I want the behavior of a
>     >      smart UA to be able to override the behavior
>     >      (provided by proxies in the network) to dumb
>     >      UAs.
>     >
>     >      Unfortunately, Po gets a chance to divert the
>     >      call first:
>     >      Proxy: Event based call diversion (recursive)
>     >      A                  Po             Pt
>     >      AnnServer
>     >      |                  |              |
>     >      |
>     >      |--INV Bob@B------>|              |
>     >      |
>     >      |                  |--INV Bob@B-->|
>     >      |
>     >      |                  |<-404---------|
>     >      |
>     >      |            proxy implements     |
>     >      |
>     >      |            call forward on 404  |
>     >      |
>     >      |                  |--INV
>     >      AnnServer------------>|
>     >      |                  |  Diversion: Bob@B
>     >      |
>     >      |                  |              |
>     >      |
>     >
>     >      <-200------------------------------------------|
>     >
>     >      |<==="The URL you have dialed B...O...B is
>     >      not==|
>     >      |     in service, please check the URL or dial
>     >      |
>     >      |     the operator for assistance"
>     >
>     >      Solution 1a: Non-recursive implementation of
>     >      call diversion
>     >      A possible solution would be to implement the
>     >      diversion non-recursively:
>     >      Proxy: Event based call diversion
>     >      (non-recursive)
>     >      A                  Po             Pt
>     >      AnnServer
>     >      |                  |              |
>     >      |
>     >      |--INV Bob@B------>|              |
>     >      |
>     >      |                  |--INV Bob@B-->|
>     >      |
>     >      |                  |<-404---------|
>     >      |
>     >      |            proxy implements     |
>     >      |
>     >      |            non-recursive        |
>     >      |
>     >      |            call forward on 404  |
>     >      |
>     >      |<-302-------------|              |
>     >      |
>     >      |  Contact: AnnServer             |
>     >      |
>     >      |  Diversion: Bob@B; reason=404   |
>     >      |
>     >      |                  |              |
>     >      |
>     >      |--INV
>     >      AnnServer------------------------------->|
>     >      |  Diversion: Bob@B; reason=404   |
>     >      |
>     >      |                  |              |
>     >      |
>     >
>     >      <-200------------------------------------------|
>     >
>     >      |<==="The URL you have dialed B...O...B is
>     >      not==|
>     >      |     in service, please check the URL or dial
>     >      |
>     >      |     the operator for assistance"
>     >
>     >      then the feature interaction could be:
>     >      A ignores 302s with Diversion header indicating
>     >      reason codes for which A local generation of
>     >      annoucements.
>     >      Proxy: Event based call diversion
>     >      (non-recursive)
>     >      User agent: Event based local announcement
>     >      (overriding 302s with already covered Diversion
>     >      reason codes)
>     >      A                  Po             Pt
>     >      AnnServer
>     >      |                  |              |
>     >      |
>     >      |--INV Bob@B------>|              |
>     >      |
>     >      |                  |--INV Bob@B-->|
>     >      |
>     >      |                  |<-404---------|
>     >      |
>     >      |            proxy implements     |
>     >      |
>     >      |            non-recursive        |
>     >      |
>     >      |            call forward on 404  |
>     >      |
>     >      |<-302-------------|              |
>     >      |
>     >      |  Contact: AnnServer             |
>     >      |
>     >      |  Diversion: Bob@B; reason=404   |
>     >      |
>     >      |                  |              |
>     >      |
>     >      A generates
>     >      local audio
>     >      indicating
>     >      "The URL you have dialed B...O...B is not in
>     >      service, please check the
>     >       URL or dial the operator for assistance."
>     >
>     >      Solution 1b: "Supported: annoucements" header
>     >      Another possible solution would be for smart UAs
>     >      (that support announcements) to use a
>     >      "Supported: annoucements" header.  This
>     >      supported header would be used to indicate to
>     >      proxies that they should not implement event
>     >      based call forwarding (for annoucements):
>     >
>     >      Proxy: Event based call diversion (deferring
>     >      implementation to UAC when "Supported:
>     >      annoucements" is present)
>     >      User agent: Event based local announcement
>     >      A                 Po             Pt
>     >      |                  |              |
>     >      |--INV Bob@B------>|              |
>     >      |  Supported: annoucements        |
>     >      |                  |              |
>     >      |<-404-------------|              |
>     >      |                  |              |
>     >      A generates
>     >      local audio
>     >      indicating
>     >      "The URL you have dialed B...O...B is not in
>     >      service, please check the
>     >       URL or dial the operator for assistance."
>     >
>     >
>     >
>     >      Desired behavior 2:  There should be a mechanism
>     >      so that announcements are not billable.
>     >
>     >      Another issue that has been raised w/r/t
>     >      annoucements in networks where SIP signalling is
>     >      billable.  The concern is that in SIP networks
>     >      where 200 is used to write a start record,
>     >      implementation of proxy event based call
>     >      diversion might generate a charge.
>     >
>     >      Solution 2a: Play annoucements as early media
>     >      One solution that has been proposed is to play
>     >      annoucements as early media:
>     >
>     >      For example, recursively:
>     >      A                  Po             Pt
>     >      AnnServer
>     >      |                  |              |
>     >      |
>     >      |--INV Bob@B------>|              |
>     >      |
>     >      |                  |--INV Bob@B-->|
>     >      |
>     >      |                  |<-404---------|
>     >      |
>     >      |            proxy implements     |
>     >      |
>     >      |            call forward on 404  |
>     >      |
>     >      |                  |--INV
>     >      AnnServer------------>|
>     >      |                  |  Diversion: Bob@B
>     >      |
>     >      |                  |              |
>     >      |
>     >
>     >      <-183------------------------------------------|
>     >
>     >      |  Content-Disposition: session
>     >      |
>     >      |<==="The URL you have dialed B...O...B is
>     >      not==|
>     >      |     in service, please check the URL or dial
>     >      |
>     >      |     the operator for assistance"
>     >
>     >      <-CANCEL---------------------------------------|
>     >
>     >      |--200
>     >      (CANCEL)-------------------------------->|
>     >
>     >      or non-recursively:
>     >      A                  Po             Pt
>     >      AnnServer
>     >      |                  |              |
>     >      |
>     >      |--INV Bob@B------>|              |
>     >      |
>     >      |                  |--INV Bob@B-->|
>     >      |
>     >      |                  |<-404---------|
>     >      |
>     >      |            proxy implements     |
>     >      |
>     >      |            non-recursive        |
>     >      |
>     >      |            call forward on 404  |
>     >      |
>     >      |<-302-------------|              |
>     >      |
>     >      |  Contact: AnnServer             |
>     >      |
>     >      |  Diversion: Bob@B; reason=404   |
>     >      |
>     >      |                  |              |
>     >      |
>     >      |--INV
>     >      AnnServer------------------------------->|
>     >      |  Diversion: Bob@B; reason=404   |
>     >      |
>     >      |                  |              |
>     >      |
>     >
>     >      <-183------------------------------------------|
>     >
>     >      |  Content-Disposition: session
>     >      |
>     >      |<==="The URL you have dialed B...O...B is
>     >      not==|
>     >      |     in service, please check the URL or dial
>     >      |
>     >      |     the operator for assistance"
>     >
>     >      <-CANCEL---------------------------------------|
>     >
>     >      |--200
>     >      (CANCEL)-------------------------------->|
>     >
>     >      Solution 2b: Backend billing system is aware of
>     >      (non-billable) Announcement Server URL
>     >      Another possible solution is that the URL of the
>     >      AnnServer could be well-known to the backend
>     >      billing system and that any accounting records
>     >      written connection to the AnnServer would not be
>     >      billed.
>     >
>     >      I'd like to solicit others' ideas, problems, and
>     >      proposed solutions w/r/t annoucements in SIP.
>     >
>     >      I'm also looking for co-authors to write an I-D
>     >      w/r/t announcements.  If interested, please
>     >      contact me directly at byerly@cisco.com.
>     >
>     >      thanks for your help,
>     >      Bryan
>     >
>     >      Bryan J. Byerly
>     >      byerly@cisco.com
>     >
>     >
>     >
>
>
>

--------------638E88A656E93C34FA039F90
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Venkatesh Venkataramanan wrote:
<blockquote TYPE=CITE>&nbsp;<span 
class=062153219-24012001><font face="Arial"><font color="#0000FF"><font size=-1>Hi.</font></font></font></span><span 
class=062153219-24012001><font face="Arial"><font color="#0000FF"><font size=-1>Thought
I had forwarded this email back to you, but haven't heard from you since.
Is this a viable suggestion??&nbsp;</font></font></font></span>
<p>Sorry for my slow response.&nbsp; I was on jury duty the past two days.&nbsp;
I'm back now.
<br><font face="Arial"><font color="#0000FF"><font size=-1></font></font></font>&nbsp;<span 
class=062153219-24012001></span><span class=062153219-24012001><font face="Arial"><font color="#0000FF"><font size=-1>Cheers!</font></font></font></span>
<div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Venkatesh Venkataramanan</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Monday, January 22,
2001 1:31 PM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> 'Bryan Byerly'; Venkatesh
Venkataramanan; sip@lists.bell-labs.com</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> RE: [SIP] Announcements
in SIP</font></font>
<br>&nbsp;</div>
<span class=421564519-22012001><font face="Arial"><font color="#0000FF"><font size=-1>I
think usage of the diversion-info here is a nice way to notify the annc-server.
For over-coming the problem with dumb UA's may be we can use something
similar to Alert-Info extension that was proposed to provide alternate
information as regards call progress, infact I propose to rename Alert-Info
to CallProgress-Info so that this header may be used to report call progress/status
of any calls, not just alerting. What do u think of this ? This header
could provide inforamation for playing the particular annc.</font></font></font>
<p>Can you point me to the I-D&nbsp;or discussion thread that describes
Alert-Info?&nbsp; I'm afraid I've missed it.
<p></span><span 
class=421564519-22012001></span><span class=421564519-22012001><font face="Arial"><font color="#0000FF"><font size=-1>So
to summarize my thoughts a 404 response shall contain a CallProgress-Info
which provides information to dumb UA's as regards annc. Smart UA's can
ignore this information and provide local annc. Does this sound reasonable?
Any repercussions??</font></font></font></span><span 
class=421564519-22012001></span><span 
class=421564519-22012001><font face="Arial"><font color="#0000FF"><font size=-1>Venkatesh</font></font></font></span><span 
class=421564519-22012001></span><span 
class=421564519-22012001></span><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Bryan Byerly [<A HREF="mailto:byerly@cisco.com">mailto:byerly@cisco.com</A>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Monday, January 22,
2001 11:42 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> Venkatesh Venkataramanan;
sip@lists.bell-labs.com</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> byerly@cisco.com</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> Re: [SIP] Announcements
in SIP</font></font>
<br>&nbsp;
<blockquote>Venkatesh Venkataramanan wrote:
<blockquote TYPE="CITE"><span class=593565817-22012001><font face="Arial"><font color="#0000FF"><font size=-1>Alternate
Suggestion:</span><span class=593565817-22012001>If I understand 404 response
right, all that the proxies do today is to forward them down to the UA.
So, instead of making the proxy either translate the 404 to a 302 or implementing
call forwarding to an annc server on receipt of a 404, I was thinking more
on the lines of just forwarding the 404 response down to the UA, very much
like today, except that the proxy adds a Contact: AnncServer_URL. A smart
UA (that can provide local annc would do so, seeing the 404) where as a
UA that doesn't have any local playback capabilities would contact the
Contact: URL to provide local announcements. So, no extensions involved
(except the work of adding a Contact in a 404 response).</span><span 
    class=593565817-22012001>Any
thoughts on this suggestion?</font></font></font></span></blockquote>

<p><br>The approach using a Contact in the response would also work for
smart UAs.
<p><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;
|</tt>
<br><tt>|--INV Bob@Po->|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@Pt->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;
|</tt>
<br><tt>|&lt;-404---------|&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;
|</tt>
<br><tt>|&nbsp; Contact: AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;
|</tt>
<br><tt>|--INV AnnServer------------------------------>|</tt>
<br><tt>|&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;&nbsp;
|</tt>
<br><tt>|&lt;-183/200-------------------------------------|</tt>
<br><tt>|&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;&nbsp;
|</tt>
<br><tt>|&lt;="The URL you have dialed B...O...B at Pt is=|</tt>
<br><tt>|&nbsp;&nbsp; unrouteable, please check the URL or&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp; contact your system admin for assistance"&nbsp; |</tt>
<br>&nbsp;
<br>&nbsp;
<p>However,
<br>a) this doesn't provide an announcements solution for dumb UAs
<br>b) I doubt a smart UA would even need an AnnServer contact.&nbsp; Since
he's smart, he would either 1) be able to generate annoucements locally
or 2) know the FQDN/IP address of the AnnServer directly.&nbsp; I'm not
aware that smart UAs need any proxy assist. (Although, they would need
to be able to turn off proxy assist).
<p>In the proposal above, how would the Announcement server know to say
"B...O...B"?
<br>One solution would be for the Annoucement server to examine the Diversion
header (draft-levy-sip-diversion-01.txt).&nbsp; The Diversion header provides
the necessary supplemental information to the announcement server.&nbsp;
Since the Diversion header is already needed for voicemail servers, I think
it is a good candidate for usage here.
<p>What do you think?
<p>thanks,
<br>Bryan
<p>Bryan J. Byerly
<br>byerly@cisco.com
<br>&nbsp;
<blockquote TYPE="CITE">
<blockquote style="MARGIN-RIGHT: 0px">
<div class=OutlookMessageHeader dir=ltr><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Bryan Byerly [<a href="mailto:byerly@cisco.com">mailto:byerly@cisco.com</a>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Monday, January 22,
2001 8:54 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> sip@lists.bell-labs.com</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> byerly@cisco.com</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> [SIP] Announcements
in SIP</font></font></div>
Hi guys,
<p>I'd like to solicit ideas/consensus w/r/t announcements in SIP.
<p>For this thread of discussion, we're talking about announcements which
are played when an error occurred during call setup.&nbsp; For instance,
on 404, a message could be played "The URL you have dialed B...O...B. is
not in service, please check the URL or dial the operator for assistance".
<p>There are at least two desired behaviors w/r/t annoucements:
<br>Desired behavior 1: There should be a mechanism so that local annoucements
override network annoucements.
<br>Desired behavior 2: There should be a mechanism so that announcements
are not billable.
<p>Like call forwarding features in SIP, there are implementable solutions
to play annoucements using user agents or proxies.
<p>In the diagrams below, A, B, and C are user agents, Po is an originating
proxy and Pt is a terminating proxy.
<p>User agent: Event based local announcement
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt</tt>
<br><tt>|&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;
|</tt>
<br><tt>|--INV Bob@B------>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;
|</tt>
<br><tt>|&lt;-404-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;
|</tt>
<br><tt>A generates</tt>
<br><tt>local audio</tt>
<br><tt>indicating</tt>
<br><tt>"The URL you have dialed B...O...B is not in service, please check
the</tt>
<br><tt>&nbsp;URL or dial the operator for assistance."</tt>
<br>&nbsp;
<p>Proxy: Event based call diversion (recursive)
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Announcement</tt>
<br><tt>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Server</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV AnnServer------------>|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Diversion: Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-200------------------------------------------|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<br>&nbsp;
<p>Both approaches are viable and there are advantages/disadvantages to
each.&nbsp; If all user agents supported local generation of announcements,
then an event based call diversion solution may not be needed.&nbsp; However,
in today's world, many user agent implementations do not have support for
generating local announcements.
<p>Advantages for "event based local announcements"
<br>a) requires no network bandwidth
<br>b) requires no annoucements server
<p>Disadvantages for "event based local announcements"
<br>a) Not all SIP user agents support locally generated announcements
<br>b) provisioning issues for large-scale deployments. (i.e. If desirable,
how would a network admin configure multi-vendor SIP phones in his net
with certain announcements).
<p>Advantages for "event based call diversion"
<br>a) Provides annoucement support in multi-vendor networks across all
SIP user agents
<br>b) Provisioning is centralized at proxy and announcement server
<p>Disadvantages for "event based call diversion"
<br>a) requires network bandwidth to play annoucements
<br>b) requires presence of an announcements server
<p>I'm not interested in a holy war of which to use.&nbsp; Each solution
will be appropriate for certain network deployments.&nbsp; There will soon
be implementations of event based local annoucements and event based call
diversion.&nbsp; The more important issue is to define a mechanism to get
desired feature interaction.
<br>&nbsp;
<br>&nbsp;
<p>Desired behavior 1: There should be a mechanism so that local annoucements
override network annoucements.
<p>I would like the behavior that locally generated annoucements take precendence
over proxy event based call diversion.&nbsp; In other words, given a UA
that is configured to play announcement X and proxy that is configured
to divert to an announcement server to play message Y, I want X to be played.&nbsp;
i.e. I want the behavior of a smart UA to be able to override the behavior
(provided by proxies in the network) to dumb UAs.
<p>Unfortunately, Po gets a chance to divert the call first:
<br>Proxy: Event based call diversion (recursive)
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV AnnServer------------>|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Diversion: Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-200------------------------------------------|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<p>Solution 1a: Non-recursive implementation of call diversion
<br>A possible solution would be to implement the diversion non-recursively:
<br>Proxy: Event based call diversion (non-recursive)
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-302-------------|&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;
|</tt>
<br><tt>|&nbsp; Contact: AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV AnnServer------------------------------->|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-200------------------------------------------|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<p>then the feature interaction could be:
<br>A ignores 302s with Diversion header indicating reason codes for which
A local generation of annoucements.
<br>Proxy: Event based call diversion (non-recursive)
<br>User agent: Event based local announcement (overriding 302s with already
covered Diversion reason codes)
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-302-------------|&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;
|</tt>
<br><tt>|&nbsp; Contact: AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>A generates</tt>
<br><tt>local audio</tt>
<br><tt>indicating</tt>
<br><tt>"The URL you have dialed B...O...B is not in service, please check
the</tt>
<br><tt>&nbsp;URL or dial the operator for assistance."</tt>
<p>Solution 1b: "Supported: annoucements" header
<br>Another possible solution would be for smart UAs (that support announcements)
to use a "Supported: annoucements" header.&nbsp; This supported header
would be used to indicate to proxies that they should not implement event
based call forwarding (for annoucements):
<p>Proxy: Event based call diversion (deferring implementation to UAC when
"Supported: annoucements" is present)
<br>User agent: Event based local announcement
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt</tt>
<br><tt>|&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;
|</tt>
<br><tt>|--INV Bob@B------>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp; Supported: annoucements&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;
|</tt>
<br><tt>|&lt;-404-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;
|</tt>
<br><tt>A generates</tt>
<br><tt>local audio</tt>
<br><tt>indicating</tt>
<br><tt>"The URL you have dialed B...O...B is not in service, please check
the</tt>
<br><tt>&nbsp;URL or dial the operator for assistance."</tt>
<br>&nbsp;
<br>&nbsp;
<p>Desired behavior 2:&nbsp; There should be a mechanism so that announcements
are not billable.
<p>Another issue that has been raised w/r/t annoucements in networks where
SIP signalling is billable.&nbsp; The concern is that in SIP networks where
200 is used to write a start record, implementation of proxy event based
call diversion might generate a charge.
<p>Solution 2a: Play annoucements as early media
<br>One solution that has been proposed is to play annoucements as early
media:
<p>For example, recursively:
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV AnnServer------------>|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Diversion: Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-183------------------------------------------|</tt>
<br><tt>|&nbsp; Content-Disposition: session&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<br><tt>|&lt;-CANCEL---------------------------------------|</tt>
<br><tt>|--200 (CANCEL)-------------------------------->|</tt>
<p>or non-recursively:
<br><tt>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV Bob@B------>|&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;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|--INV Bob@B-->|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
proxy implements&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
call forward on 404&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-302-------------|&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;
|</tt>
<br><tt>|&nbsp; Contact: AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|--INV AnnServer------------------------------->|</tt>
<br><tt>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&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;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;-183------------------------------------------|</tt>
<br><tt>|&nbsp; Content-Disposition: session&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&lt;==="The URL you have dialed B...O...B is not==|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or dial&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for assistance"</tt>
<br><tt>|&lt;-CANCEL---------------------------------------|</tt>
<br><tt>|--200 (CANCEL)-------------------------------->|</tt>
<p>Solution 2b: Backend billing system is aware of (non-billable) Announcement
Server URL
<br>Another possible solution is that the URL of the AnnServer could be
well-known to the backend billing system and that any accounting records
written connection to the AnnServer would not be billed.
<p>I'd like to solicit others' ideas, problems, and proposed solutions
w/r/t annoucements in SIP.
<p>I'm also looking for co-authors to write an I-D w/r/t announcements.&nbsp;
If interested, please contact me directly at byerly@cisco.com.
<p>thanks for your help,
<br>Bryan
<p>Bryan J. Byerly
<br>byerly@cisco.com
<br>&nbsp;
<br>&nbsp;</blockquote>
</blockquote>

<br>&nbsp;</blockquote>
</blockquote>
</html>

--------------638E88A656E93C34FA039F90--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 16:24:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09204
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 16:24:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id CE5604437E; Thu, 25 Jan 2001 15:25:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 80C5D44336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 15:24:18 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02617;
	Thu, 25 Jan 2001 13:23:54 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03580;
	Thu, 25 Jan 2001 13:23:51 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA18614;
	Thu, 25 Jan 2001 13:23:38 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: Re: [SIP] T2 and 182 Queued
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        christopher.a.martin@wcom.com,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" <3A7092A2.21DD6514@cs.columbia.edu>
Message-ID: <Roam.SIMC.2.0.6.980457818.27647.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 13:23:38 -0800 (PST)

> Patrice Calhoun wrote:
> > 
> 
> > (in any case, it sounds so much simpler to fix the protocol than to require
> > firewalls)
> 
> Suggestions are welcome, but I would guess that any such fix will
> increase the message complexity of the non-DoS case and thus reduce
> overall throughput. For example, use of TCP and IPsec definitely will,
> due to the extra round-trip times and TCP-level messages.

ok, but I wasn't talking about adding IPSec. 

btw, I would venture a guess that a protocol that is not subject to DoS, is
better than a slightly faster one.

> 
> Thus, with a datagram protocol it is probably provably impossible to
> prevent flooding of the server, SIP or otherwise. (DNS, for example, has
> the same issue, as does any other query-response protocol.) The only
> means to avoid the amplifier effect is to require a handshake (IPsec,
> TCP, whatever) before sending more than one message.

The only way is to require a round trip, or that every datagram is secured
(see below).

> 
> All TCP SYN flood mechanisms simply minimize the amount of state that is
> committed on the server prior to completion of the handshake.
> Fortunately, SIP authentication will minimize the amount of state, if
> not computation.
> 
> For SIP, the standard (basic or digest) authentication provides such a
> handshake. If somebody attacks you with a non-authenticated request,
> reject immediately with 401/407. Don't send 100 or (if under attack)
> additional 401s. A non-malicious INVITEr will retransmit the INVITE if
> the 401 got lost. This solves the multiplier problem.
> 
> Digest already echoes back parts of the challenge, so this is as good as
> the standard IPsec anti-clogging mechanism. We don't seem to know
> anything better at this point, SIP or otherwise.
> 
> Basic is of dubious merit, but probably the CPU effort is sufficiently
> low not to matter. (The larger expense is likely to be the lookup of the
> name in larger installations, not the hash comparison.)

ok, so we mandate authentication. How will you "hgs@cs.columbia.edu" call me
"pcalhoun@eng.sun.com"? I guess there are a couple of ways: 1. Mandate that a
security relationship exists between columbia and sun (unlikely to happen
soon, but possible), and require that we send SIP messages to our respective
proxies instead of to each other's servers. 2. Mandate that we share a
security relationship with each other's servers (even less likely) 3. require
a round trip to ensure that the request wasn't spoofed.

seems like #3 above is the simplest.

> 
> 
> > sure, unless you mandate TCP, which already fixes these problems. Perhaps
> > there are other ways, and I wouldn't be against looking at different solutions.
> 
> TCP does not fix the problem in any magic way. See above.

I must have missed the part where you explained why it didn't fix the problem
:( > 
> >  >
> > > I also believe that SIP awareness needs to be implemented on firewalls and
> > > intrusion detection systems.
> 
> > Putting a cert on the SIP server is a quarter (or even less) of the problem.
> > The issue then is to distribute certificates with ANYONE that will communicate
> > with your SIP server (and I DO mean anyone!). If my grand-mother wants to call
> > you, must she first go to her favorite PKI vendor and get a signed cert?
> 
> No, but see our approach in sipd for a workable, albeit less than 100%
> secure mechanism of authentication of "first-time callers".

Could I get a pointer?

PatC


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 16:27:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09221
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 16:27:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0B60F443CC; Thu, 25 Jan 2001 15:28:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id 2E50644336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 15:27:56 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17727;
	Thu, 25 Jan 2001 13:27:28 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA04456;
	Thu, 25 Jan 2001 13:27:27 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id NAA18665;
	Thu, 25 Jan 2001 13:27:22 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: RE: [SIP] T2 and 182 Queued
To: christopher.a.martin@wcom.com
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" <001501c08712$773e3320$6401010a@mcit.com>
Message-ID: <Roam.SIMC.2.0.6.980458043.3511.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 13:27:23 -0800 (PST)

> This is just an assumption on my part, but as SIP gets implemented as a
> service by many providers couldn't the user receive a cert as part of the
> sign up process, using the providers public certificate server.
> 
> With this type of scenario the provideer would have information on file
> about the user which is where accountability would come in. I am in no way
> an authority on certificate authorities, this is just an thought on my part.

yes you could, but then you would have to explain to your customers why they
can only receive calls from people that are in your little boys club :)

My problem is that I envisoned SIP as taking over alot of today's PSTN calls,
and if this requires that every person gets a cert that has the same trusted
root CA, it will take a long time.

Maybe it's just my imagination :(

PatC


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 16:32:50 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09317
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 16:32:48 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C5ED0443F5; Thu, 25 Jan 2001 15:30:07 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailserver.sylantro.com (smtp2.sylantro.com [38.185.174.4])
	by lists.bell-labs.com (Postfix) with SMTP id 8C7B4443F3
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 15:29:58 -0500 (EST)
Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP (
 Tumbleweed MMS SMTP Relay (MMS v4.7)); Thu, 25 Jan 2001 13:29:05 -0800
X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900
Received: by mailserver.sylantro.com with Internet Mail Service (
 5.5.2653.19) id <DS5D586Z>; Thu, 25 Jan 2001 13:29:05 -0800
Message-ID: <79FEAA5FABA7D411BF580001023D1BBD2A2D3D@mailserver.sylantro.com>
From: "Venkatesh Venkataramanan" <Venkatesh.Venkataramanan@sylantro.com>
To: "Bryan Byerly" <byerly@cisco.com>,
        "Venkatesh Venkataramanan" <Venkatesh.Venkataramanan@sylantro.com>
Cc: sip@lists.bell-labs.com
Subject: RE: FW: [SIP] Announcements in SIP
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 166E452B69794-01-01
Content-Type: multipart/alternative; 
 boundary="----_=_NextPart_001_01C08715.D3920900"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 13:28:58 -0800

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_01C08715.D3920900
Content-Type: text/plain; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit

I see Alert-Info defined in the latest rfc. Section 6.9 in
ietf-sip-rfc2543bis-02.ps talks about this header. 

-----Original Message-----
From: Bryan Byerly [mailto:byerly@cisco.com]
Sent: Thursday, January 25, 2001 1:07 PM
To: Venkatesh Venkataramanan
Cc: sip@lists.bell-labs.com; byerly@cisco.com
Subject: Re: FW: [SIP] Announcements in SIP


Venkatesh Venkataramanan wrote: 

 Hi.Thought I had forwarded this email back to you, but haven't heard from
you since. Is this a viable suggestion??  

Sorry for my slow response.  I was on jury duty the past two days.  I'm back
now. 
 Cheers! 

-----Original Message----- 
From: Venkatesh Venkataramanan 
Sent: Monday, January 22, 2001 1:31 PM 
To: 'Bryan Byerly'; Venkatesh Venkataramanan; sip@lists.bell-labs.com 
Subject: RE: [SIP] Announcements in SIP 
 
I think usage of the diversion-info here is a nice way to notify the
annc-server. For over-coming the problem with dumb UA's may be we can use
something similar to Alert-Info extension that was proposed to provide
alternate information as regards call progress, infact I propose to rename
Alert-Info to CallProgress-Info so that this header may be used to report
call progress/status of any calls, not just alerting. What do u think of
this ? This header could provide inforamation for playing the particular
annc. 

Can you point me to the I-D or discussion thread that describes Alert-Info?
I'm afraid I've missed it. 


So to summarize my thoughts a 404 response shall contain a CallProgress-Info
which provides information to dumb UA's as regards annc. Smart UA's can
ignore this information and provide local annc. Does this sound reasonable?
Any repercussions??Venkatesh-----Original Message----- 
From: Bryan Byerly [ mailto:byerly@cisco.com <mailto:byerly@cisco.com> ] 
Sent: Monday, January 22, 2001 11:42 AM 
To: Venkatesh Venkataramanan; sip@lists.bell-labs.com 
Cc: byerly@cisco.com 
Subject: Re: [SIP] Announcements in SIP 
  


Venkatesh Venkataramanan wrote: 

Alternate Suggestion:If I understand 404 response right, all that the
proxies do today is to forward them down to the UA. So, instead of making
the proxy either translate the 404 to a 302 or implementing call forwarding
to an annc server on receipt of a 404, I was thinking more on the lines of
just forwarding the 404 response down to the UA, very much like today,
except that the proxy adds a Contact: AnncServer_URL. A smart UA (that can
provide local annc would do so, seeing the 404) where as a UA that doesn't
have any local playback capabilities would contact the Contact: URL to
provide local announcements. So, no extensions involved (except the work of
adding a Contact in a 404 response).Any thoughts on this suggestion?


The approach using a Contact in the response would also work for smart UAs. 


A              Po             Pt           AnnServer 
|              |              |                | 
|--INV Bob@Po->|              |                | 
|              |--INV Bob@Pt->|                | 
|              |              |                | 
|              |<-404---------|                | 
|              |              |                | 
|<-404---------|              |                | 
|  Contact: AnnServer         |                | 
|              |              |                | 
|--INV AnnServer------------------------------>| 
|              |              |                | 
|<-183/200-------------------------------------| 
|              |              |                | 
|<="The URL you have dialed B...O...B at Pt is=| 
|   unrouteable, please check the URL or       | 
|   contact your system admin for assistance"  | 
  
  


However, 
a) this doesn't provide an announcements solution for dumb UAs 
b) I doubt a smart UA would even need an AnnServer contact.  Since he's
smart, he would either 1) be able to generate annoucements locally or 2)
know the FQDN/IP address of the AnnServer directly.  I'm not aware that
smart UAs need any proxy assist. (Although, they would need to be able to
turn off proxy assist). 


In the proposal above, how would the Announcement server know to say
"B...O...B"? 
One solution would be for the Annoucement server to examine the Diversion
header (draft-levy-sip-diversion-01.txt).  The Diversion header provides the
necessary supplemental information to the announcement server.  Since the
Diversion header is already needed for voicemail servers, I think it is a
good candidate for usage here. 


What do you think? 


thanks, 
Bryan 


Bryan J. Byerly 
byerly@cisco.com 
  


-----Original Message----- 
From: Bryan Byerly [ mailto:byerly@cisco.com <mailto:byerly@cisco.com> ] 
Sent: Monday, January 22, 2001 8:54 AM 
To: sip@lists.bell-labs.com 
Cc: byerly@cisco.com 
Subject: [SIP] Announcements in SIP
Hi guys, 

I'd like to solicit ideas/consensus w/r/t announcements in SIP. 


For this thread of discussion, we're talking about announcements which are
played when an error occurred during call setup.  For instance, on 404, a
message could be played "The URL you have dialed B...O...B. is not in
service, please check the URL or dial the operator for assistance". 


There are at least two desired behaviors w/r/t annoucements: 
Desired behavior 1: There should be a mechanism so that local annoucements
override network annoucements. 
Desired behavior 2: There should be a mechanism so that announcements are
not billable. 


Like call forwarding features in SIP, there are implementable solutions to
play annoucements using user agents or proxies. 


In the diagrams below, A, B, and C are user agents, Po is an originating
proxy and Pt is a terminating proxy. 


User agent: Event based local announcement 
A                 Po             Pt 
|                  |              | 
|--INV Bob@B------>|              | 
|                  |              | 
|<-404-------------|              | 
|                  |              | 
A generates 
local audio 
indicating 
"The URL you have dialed B...O...B is not in service, please check the 
 URL or dial the operator for assistance." 
  


Proxy: Event based call diversion (recursive) 
A                  Po             Pt        Announcement 
                                              Server 
|                  |              |             | 
|--INV Bob@B------>|              |             | 
|                  |--INV Bob@B-->|             | 
|                  |<-404---------|             | 
|            proxy implements     |             | 
|            call forward on 404  |             | 
|                  |--INV AnnServer------------>| 
|                  |  Diversion: Bob@B          | 
|                  |              |             | 
|<-200------------------------------------------| 
|<==="The URL you have dialed B...O...B is not==| 
|     in service, please check the URL or dial  | 
|     the operator for assistance" 
  


Both approaches are viable and there are advantages/disadvantages to each.
If all user agents supported local generation of announcements, then an
event based call diversion solution may not be needed.  However, in today's
world, many user agent implementations do not have support for generating
local announcements. 


Advantages for "event based local announcements" 
a) requires no network bandwidth 
b) requires no annoucements server 


Disadvantages for "event based local announcements" 
a) Not all SIP user agents support locally generated announcements 
b) provisioning issues for large-scale deployments. (i.e. If desirable, how
would a network admin configure multi-vendor SIP phones in his net with
certain announcements). 


Advantages for "event based call diversion" 
a) Provides annoucement support in multi-vendor networks across all SIP user
agents 
b) Provisioning is centralized at proxy and announcement server 


Disadvantages for "event based call diversion" 
a) requires network bandwidth to play annoucements 
b) requires presence of an announcements server 


I'm not interested in a holy war of which to use.  Each solution will be
appropriate for certain network deployments.  There will soon be
implementations of event based local annoucements and event based call
diversion.  The more important issue is to define a mechanism to get desired
feature interaction. 
  
  


Desired behavior 1: There should be a mechanism so that local annoucements
override network annoucements. 


I would like the behavior that locally generated annoucements take
precendence over proxy event based call diversion.  In other words, given a
UA that is configured to play announcement X and proxy that is configured to
divert to an announcement server to play message Y, I want X to be played.
i.e. I want the behavior of a smart UA to be able to override the behavior
(provided by proxies in the network) to dumb UAs. 


Unfortunately, Po gets a chance to divert the call first: 
Proxy: Event based call diversion (recursive) 
A                  Po             Pt         AnnServer 
|                  |              |             | 
|--INV Bob@B------>|              |             | 
|                  |--INV Bob@B-->|             | 
|                  |<-404---------|             | 
|            proxy implements     |             | 
|            call forward on 404  |             | 
|                  |--INV AnnServer------------>| 
|                  |  Diversion: Bob@B          | 
|                  |              |             | 
|<-200------------------------------------------| 
|<==="The URL you have dialed B...O...B is not==| 
|     in service, please check the URL or dial  | 
|     the operator for assistance" 


Solution 1a: Non-recursive implementation of call diversion 
A possible solution would be to implement the diversion non-recursively: 
Proxy: Event based call diversion (non-recursive) 
A                  Po             Pt         AnnServer 
|                  |              |             | 
|--INV Bob@B------>|              |             | 
|                  |--INV Bob@B-->|             | 
|                  |<-404---------|             | 
|            proxy implements     |             | 
|            non-recursive        |             | 
|            call forward on 404  |             | 
|<-302-------------|              |             | 
|  Contact: AnnServer             |             | 
|  Diversion: Bob@B; reason=404   |             | 
|                  |              |             | 
|--INV AnnServer------------------------------->| 
|  Diversion: Bob@B; reason=404   |             | 
|                  |              |             | 
|<-200------------------------------------------| 
|<==="The URL you have dialed B...O...B is not==| 
|     in service, please check the URL or dial  | 
|     the operator for assistance" 


then the feature interaction could be: 
A ignores 302s with Diversion header indicating reason codes for which A
local generation of annoucements. 
Proxy: Event based call diversion (non-recursive) 
User agent: Event based local announcement (overriding 302s with already
covered Diversion reason codes) 
A                  Po             Pt         AnnServer 
|                  |              |             | 
|--INV Bob@B------>|              |             | 
|                  |--INV Bob@B-->|             | 
|                  |<-404---------|             | 
|            proxy implements     |             | 
|            non-recursive        |             | 
|            call forward on 404  |             | 
|<-302-------------|              |             | 
|  Contact: AnnServer             |             | 
|  Diversion: Bob@B; reason=404   |             | 
|                  |              |             | 
A generates 
local audio 
indicating 
"The URL you have dialed B...O...B is not in service, please check the 
 URL or dial the operator for assistance." 


Solution 1b: "Supported: annoucements" header 
Another possible solution would be for smart UAs (that support
announcements) to use a "Supported: annoucements" header.  This supported
header would be used to indicate to proxies that they should not implement
event based call forwarding (for annoucements): 


Proxy: Event based call diversion (deferring implementation to UAC when
"Supported: annoucements" is present) 
User agent: Event based local announcement 
A                 Po             Pt 
|                  |              | 
|--INV Bob@B------>|              | 
|  Supported: annoucements        | 
|                  |              | 
|<-404-------------|              | 
|                  |              | 
A generates 
local audio 
indicating 
"The URL you have dialed B...O...B is not in service, please check the 
 URL or dial the operator for assistance." 
  
  


Desired behavior 2:  There should be a mechanism so that announcements are
not billable. 


Another issue that has been raised w/r/t annoucements in networks where SIP
signalling is billable.  The concern is that in SIP networks where 200 is
used to write a start record, implementation of proxy event based call
diversion might generate a charge. 


Solution 2a: Play annoucements as early media 
One solution that has been proposed is to play annoucements as early media: 


For example, recursively: 
A                  Po             Pt         AnnServer 
|                  |              |             | 
|--INV Bob@B------>|              |             | 
|                  |--INV Bob@B-->|             | 
|                  |<-404---------|             | 
|            proxy implements     |             | 
|            call forward on 404  |             | 
|                  |--INV AnnServer------------>| 
|                  |  Diversion: Bob@B          | 
|                  |              |             | 
|<-183------------------------------------------| 
|  Content-Disposition: session                 | 
|<==="The URL you have dialed B...O...B is not==| 
|     in service, please check the URL or dial  | 
|     the operator for assistance" 
|<-CANCEL---------------------------------------| 
|--200 (CANCEL)-------------------------------->| 


or non-recursively: 
A                  Po             Pt         AnnServer 
|                  |              |             | 
|--INV Bob@B------>|              |             | 
|                  |--INV Bob@B-->|             | 
|                  |<-404---------|             | 
|            proxy implements     |             | 
|            non-recursive        |             | 
|            call forward on 404  |             | 
|<-302-------------|              |             | 
|  Contact: AnnServer             |             | 
|  Diversion: Bob@B; reason=404   |             | 
|                  |              |             | 
|--INV AnnServer------------------------------->| 
|  Diversion: Bob@B; reason=404   |             | 
|                  |              |             | 
|<-183------------------------------------------| 
|  Content-Disposition: session                 | 
|<==="The URL you have dialed B...O...B is not==| 
|     in service, please check the URL or dial  | 
|     the operator for assistance" 
|<-CANCEL---------------------------------------| 
|--200 (CANCEL)-------------------------------->| 


Solution 2b: Backend billing system is aware of (non-billable) Announcement
Server URL 
Another possible solution is that the URL of the AnnServer could be
well-known to the backend billing system and that any accounting records
written connection to the AnnServer would not be billed. 


I'd like to solicit others' ideas, problems, and proposed solutions w/r/t
annoucements in SIP. 


I'm also looking for co-authors to write an I-D w/r/t announcements.  If
interested, please contact me directly at byerly@cisco.com. 


thanks for your help, 
Bryan 


Bryan J. Byerly 
byerly@cisco.com 
  
 


 


------_=_NextPart_001_01C08715.D3920900
Content-Type: text/html; 
 charset=iso-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=718372221-25012001>I see 
Alert-Info defined in the latest rfc. Section 6.9 in ietf-sip-rfc2543bis-02.ps 
talks about this header. </SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Bryan Byerly 
  [mailto:byerly@cisco.com]<BR><B>Sent:</B> Thursday, January 25, 2001 1:07 
  PM<BR><B>To:</B> Venkatesh Venkataramanan<BR><B>Cc:</B> 
  sip@lists.bell-labs.com; byerly@cisco.com<BR><B>Subject:</B> Re: FW: [SIP] 
  Announcements in SIP<BR><BR></DIV></FONT>Venkatesh Venkataramanan wrote: 
  <BLOCKQUOTE TYPE="CITE">&nbsp;<SPAN class=062153219-24012001><FONT 
    face=Arial><FONT color=#0000ff><FONT 
    size=-1>Hi.</FONT></FONT></FONT></SPAN><SPAN class=062153219-24012001><FONT 
    face=Arial><FONT color=#0000ff><FONT size=-1>Thought I had forwarded this 
    email back to you, but haven't heard from you since. Is this a viable 
    suggestion??&nbsp;</FONT></FONT></FONT></SPAN> 
    <P>Sorry for my slow response.&nbsp; I was on jury duty the past two 
    days.&nbsp; I'm back now. <BR><FONT face=Arial><FONT color=#0000ff><FONT 
    size=-1></FONT></FONT></FONT>&nbsp;<SPAN 
    class=062153219-24012001></SPAN><SPAN class=062153219-24012001><FONT 
    face=Arial><FONT color=#0000ff><FONT 
    size=-1>Cheers!</FONT></FONT></FONT></SPAN> 
    <DIV class=OutlookMessageHeader dir=ltr><FONT face=Tahoma><FONT 
    size=-1>-----Original Message-----</FONT></FONT> <BR><FONT face=Tahoma><FONT 
    size=-1><B>From:</B> Venkatesh Venkataramanan</FONT></FONT> <BR><FONT 
    face=Tahoma><FONT size=-1><B>Sent:</B> Monday, January 22, 2001 1:31 
    PM</FONT></FONT> <BR><FONT face=Tahoma><FONT size=-1><B>To:</B> 'Bryan 
    Byerly'; Venkatesh Venkataramanan; sip@lists.bell-labs.com</FONT></FONT> 
    <BR><FONT face=Tahoma><FONT size=-1><B>Subject:</B> RE: [SIP] Announcements 
    in SIP</FONT></FONT> <BR>&nbsp;</DIV><SPAN class=421564519-22012001><FONT 
    face=Arial><FONT color=#0000ff><FONT size=-1>I think usage of the 
    diversion-info here is a nice way to notify the annc-server. For over-coming 
    the problem with dumb UA's may be we can use something similar to Alert-Info 
    extension that was proposed to provide alternate information as regards call 
    progress, infact I propose to rename Alert-Info to CallProgress-Info so that 
    this header may be used to report call progress/status of any calls, not 
    just alerting. What do u think of this ? This header could provide 
    inforamation for playing the particular annc.</FONT></FONT></FONT> 
    <P>Can you point me to the I-D&nbsp;or discussion thread that describes 
    Alert-Info?&nbsp; I'm afraid I've missed it. 
    <P></SPAN><SPAN class=421564519-22012001></SPAN><SPAN 
    class=421564519-22012001><FONT face=Arial><FONT color=#0000ff><FONT 
    size=-1>So to summarize my thoughts a 404 response shall contain a 
    CallProgress-Info which provides information to dumb UA's as regards annc. 
    Smart UA's can ignore this information and provide local annc. Does this 
    sound reasonable? Any repercussions??</FONT></FONT></FONT></SPAN><SPAN 
    class=421564519-22012001></SPAN><SPAN class=421564519-22012001><FONT 
    face=Arial><FONT color=#0000ff><FONT 
    size=-1>Venkatesh</FONT></FONT></FONT></SPAN><SPAN 
    class=421564519-22012001></SPAN><SPAN class=421564519-22012001></SPAN><FONT 
    face=Tahoma><FONT size=-1>-----Original Message-----</FONT></FONT> <BR><FONT 
    face=Tahoma><FONT size=-1><B>From:</B> Bryan Byerly [<A 
    href="mailto:byerly@cisco.com">mailto:byerly@cisco.com</A>]</FONT></FONT> 
    <BR><FONT face=Tahoma><FONT size=-1><B>Sent:</B> Monday, January 22, 2001 
    11:42 AM</FONT></FONT> <BR><FONT face=Tahoma><FONT size=-1><B>To:</B> 
    Venkatesh Venkataramanan; sip@lists.bell-labs.com</FONT></FONT> <BR><FONT 
    face=Tahoma><FONT size=-1><B>Cc:</B> byerly@cisco.com</FONT></FONT> 
    <BR><FONT face=Tahoma><FONT size=-1><B>Subject:</B> Re: [SIP] Announcements 
    in SIP</FONT></FONT> <BR>&nbsp; 
    <BLOCKQUOTE>Venkatesh Venkataramanan wrote: 
      <BLOCKQUOTE TYPE="CITE"><SPAN class=593565817-22012001><FONT 
        face=Arial><FONT color=#0000ff><FONT size=-1>Alternate 
        Suggestion:</SPAN><SPAN class=593565817-22012001>If I understand 404 
        response right, all that the proxies do today is to forward them down to 
        the UA. So, instead of making the proxy either translate the 404 to a 
        302 or implementing call forwarding to an annc server on receipt of a 
        404, I was thinking more on the lines of just forwarding the 404 
        response down to the UA, very much like today, except that the proxy 
        adds a Contact: AnncServer_URL. A smart UA (that can provide local annc 
        would do so, seeing the 404) where as a UA that doesn't have any local 
        playback capabilities would contact the Contact: URL to provide local 
        announcements. So, no extensions involved (except the work of adding a 
        Contact in a 404 response).</SPAN><SPAN class=593565817-22012001>Any 
        thoughts on this suggestion?</FONT></FONT></FONT></SPAN></BLOCKQUOTE>
      <P><BR>The approach using a Contact in the response would also work for 
      smart UAs. 
      <P><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      AnnServer</TT> 
      <BR><TT>|&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;&nbsp; 
      |</TT> <BR><TT>|--INV 
      Bob@Po-&gt;|&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; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |--INV 
      Bob@Pt-&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&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;&nbsp; 
      |</TT> 
      <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&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;&nbsp; 
      |</TT> 
      <BR><TT>|&lt;-404---------|&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; 
      |</TT> <BR><TT>|&nbsp; Contact: 
      AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</TT> 
      <BR><TT>|&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;&nbsp; 
      |</TT> <BR><TT>|--INV AnnServer------------------------------&gt;|</TT> 
      <BR><TT>|&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;&nbsp; 
      |</TT> <BR><TT>|&lt;-183/200-------------------------------------|</TT> 
      <BR><TT>|&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;&nbsp; 
      |</TT> <BR><TT>|&lt;="The URL you have dialed B...O...B at Pt is=|</TT> 
      <BR><TT>|&nbsp;&nbsp; unrouteable, please check the URL 
      or&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> <BR><TT>|&nbsp;&nbsp; 
      contact your system admin for assistance"&nbsp; |</TT> <BR>&nbsp; 
      <BR>&nbsp; 
      <P>However, <BR>a) this doesn't provide an announcements solution for dumb 
      UAs <BR>b) I doubt a smart UA would even need an AnnServer contact.&nbsp; 
      Since he's smart, he would either 1) be able to generate annoucements 
      locally or 2) know the FQDN/IP address of the AnnServer directly.&nbsp; 
      I'm not aware that smart UAs need any proxy assist. (Although, they would 
      need to be able to turn off proxy assist). 
      <P>In the proposal above, how would the Announcement server know to say 
      "B...O...B"? <BR>One solution would be for the Annoucement server to 
      examine the Diversion header (draft-levy-sip-diversion-01.txt).&nbsp; The 
      Diversion header provides the necessary supplemental information to the 
      announcement server.&nbsp; Since the Diversion header is already needed 
      for voicemail servers, I think it is a good candidate for usage here. 
      <P>What do you think? 
      <P>thanks, <BR>Bryan 
      <P>Bryan J. Byerly <BR>byerly@cisco.com <BR>&nbsp; 
      <BLOCKQUOTE TYPE="CITE">
        <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
          <DIV class=OutlookMessageHeader dir=ltr><FONT face=Tahoma><FONT 
          size=-1>-----Original Message-----</FONT></FONT> <BR><FONT 
          face=Tahoma><FONT size=-1><B>From:</B> Bryan Byerly [<A 
          href="mailto:byerly@cisco.com">mailto:byerly@cisco.com</A>]</FONT></FONT> 
          <BR><FONT face=Tahoma><FONT size=-1><B>Sent:</B> Monday, January 22, 
          2001 8:54 AM</FONT></FONT> <BR><FONT face=Tahoma><FONT 
          size=-1><B>To:</B> sip@lists.bell-labs.com</FONT></FONT> <BR><FONT 
          face=Tahoma><FONT size=-1><B>Cc:</B> byerly@cisco.com</FONT></FONT> 
          <BR><FONT face=Tahoma><FONT size=-1><B>Subject:</B> [SIP] 
          Announcements in SIP</FONT></FONT></DIV>Hi guys, 
          <P>I'd like to solicit ideas/consensus w/r/t announcements in SIP. 
          <P>For this thread of discussion, we're talking about announcements 
          which are played when an error occurred during call setup.&nbsp; For 
          instance, on 404, a message could be played "The URL you have dialed 
          B...O...B. is not in service, please check the URL or dial the 
          operator for assistance". 
          <P>There are at least two desired behaviors w/r/t annoucements: 
          <BR>Desired behavior 1: There should be a mechanism so that local 
          annoucements override network annoucements. <BR>Desired behavior 2: 
          There should be a mechanism so that announcements are not billable. 
          <P>Like call forwarding features in SIP, there are implementable 
          solutions to play annoucements using user agents or proxies. 
          <P>In the diagrams below, A, B, and C are user agents, Po is an 
          originating proxy and Pt is a terminating proxy. 
          <P>User agent: Event based local announcement 
          <BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Pt</TT> 
          <BR><TT>|&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; 
          |</TT> <BR><TT>|--INV 
          Bob@B------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&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; 
          |</TT> 
          <BR><TT>|&lt;-404-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&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; 
          |</TT> <BR><TT>A generates</TT> <BR><TT>local audio</TT> 
          <BR><TT>indicating</TT> <BR><TT>"The URL you have dialed B...O...B is 
          not in service, please check the</TT> <BR><TT>&nbsp;URL or dial the 
          operator for assistance."</TT> <BR>&nbsp; 
          <P>Proxy: Event based call diversion (recursive) 
          <BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Announcement</TT> 
          <BR><TT>&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Server</TT> 
          <BR><TT>|&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;&nbsp;&nbsp; 
          |</TT> <BR><TT>|--INV 
          Bob@B------&gt;|&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; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |--INV 
          Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          proxy implements&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          call forward on 404&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |--INV AnnServer------------&gt;|</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp; Diversion: 
          Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
          <BR><TT>|&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;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&lt;-200------------------------------------------|</TT> 
          <BR><TT>|&lt;==="The URL you have dialed B...O...B is not==|</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or 
          dial&nbsp; |</TT> <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for 
          assistance"</TT> <BR>&nbsp; 
          <P>Both approaches are viable and there are advantages/disadvantages 
          to each.&nbsp; If all user agents supported local generation of 
          announcements, then an event based call diversion solution may not be 
          needed.&nbsp; However, in today's world, many user agent 
          implementations do not have support for generating local 
          announcements. 
          <P>Advantages for "event based local announcements" <BR>a) requires no 
          network bandwidth <BR>b) requires no annoucements server 
          <P>Disadvantages for "event based local announcements" <BR>a) Not all 
          SIP user agents support locally generated announcements <BR>b) 
          provisioning issues for large-scale deployments. (i.e. If desirable, 
          how would a network admin configure multi-vendor SIP phones in his net 
          with certain announcements). 
          <P>Advantages for "event based call diversion" <BR>a) Provides 
          annoucement support in multi-vendor networks across all SIP user 
          agents <BR>b) Provisioning is centralized at proxy and announcement 
          server 
          <P>Disadvantages for "event based call diversion" <BR>a) requires 
          network bandwidth to play annoucements <BR>b) requires presence of an 
          announcements server 
          <P>I'm not interested in a holy war of which to use.&nbsp; Each 
          solution will be appropriate for certain network deployments.&nbsp; 
          There will soon be implementations of event based local annoucements 
          and event based call diversion.&nbsp; The more important issue is to 
          define a mechanism to get desired feature interaction. <BR>&nbsp; 
          <BR>&nbsp; 
          <P>Desired behavior 1: There should be a mechanism so that local 
          annoucements override network annoucements. 
          <P>I would like the behavior that locally generated annoucements take 
          precendence over proxy event based call diversion.&nbsp; In other 
          words, given a UA that is configured to play announcement X and proxy 
          that is configured to divert to an announcement server to play message 
          Y, I want X to be played.&nbsp; i.e. I want the behavior of a smart UA 
          to be able to override the behavior (provided by proxies in the 
          network) to dumb UAs. 
          <P>Unfortunately, Po gets a chance to divert the call first: 
          <BR>Proxy: Event based call diversion (recursive) 
          <BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</TT> 
          <BR><TT>|&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;&nbsp;&nbsp; 
          |</TT> <BR><TT>|--INV 
          Bob@B------&gt;|&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; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |--INV 
          Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          proxy implements&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          call forward on 404&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |--INV AnnServer------------&gt;|</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp; Diversion: 
          Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
          <BR><TT>|&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;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&lt;-200------------------------------------------|</TT> 
          <BR><TT>|&lt;==="The URL you have dialed B...O...B is not==|</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or 
          dial&nbsp; |</TT> <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for 
          assistance"</TT> 
          <P>Solution 1a: Non-recursive implementation of call diversion <BR>A 
          possible solution would be to implement the diversion non-recursively: 
          <BR>Proxy: Event based call diversion (non-recursive) 
          <BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</TT> 
          <BR><TT>|&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;&nbsp;&nbsp; 
          |</TT> <BR><TT>|--INV 
          Bob@B------&gt;|&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; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |--INV 
          Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          proxy implements&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          call forward on 404&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&lt;-302-------------|&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; 
          |</TT> <BR><TT>|&nbsp; Contact: 
          AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&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;&nbsp;&nbsp; 
          |</TT> <BR><TT>|--INV 
          AnnServer-------------------------------&gt;|</TT> <BR><TT>|&nbsp; 
          Diversion: Bob@B; reason=404&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&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;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&lt;-200------------------------------------------|</TT> 
          <BR><TT>|&lt;==="The URL you have dialed B...O...B is not==|</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check the URL or 
          dial&nbsp; |</TT> <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; the operator for 
          assistance"</TT> 
          <P>then the feature interaction could be: <BR>A ignores 302s with 
          Diversion header indicating reason codes for which A local generation 
          of annoucements. <BR>Proxy: Event based call diversion (non-recursive) 
          <BR>User agent: Event based local announcement (overriding 302s with 
          already covered Diversion reason codes) 
          <BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</TT> 
          <BR><TT>|&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;&nbsp;&nbsp; 
          |</TT> <BR><TT>|--INV 
          Bob@B------&gt;|&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; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |--INV 
          Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          proxy implements&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          call forward on 404&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&lt;-302-------------|&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; 
          |</TT> <BR><TT>|&nbsp; Contact: 
          AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&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;&nbsp;&nbsp; 
          |</TT> <BR><TT>A generates</TT> <BR><TT>local audio</TT> 
          <BR><TT>indicating</TT> <BR><TT>"The URL you have dialed B...O...B is 
          not in service, please check the</TT> <BR><TT>&nbsp;URL or dial the 
          operator for assistance."</TT> 
          <P>Solution 1b: "Supported: annoucements" header <BR>Another possible 
          solution would be for smart UAs (that support announcements) to use a 
          "Supported: annoucements" header.&nbsp; This supported header would be 
          used to indicate to proxies that they should not implement event based 
          call forwarding (for annoucements): 
          <P>Proxy: Event based call diversion (deferring implementation to UAC 
          when "Supported: annoucements" is present) <BR>User agent: Event based 
          local announcement 
          <BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Pt</TT> 
          <BR><TT>|&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; 
          |</TT> <BR><TT>|--INV 
          Bob@B------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>|&nbsp; Supported: 
          annoucements&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
          <BR><TT>|&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; 
          |</TT> 
          <BR><TT>|&lt;-404-------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&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; 
          |</TT> <BR><TT>A generates</TT> <BR><TT>local audio</TT> 
          <BR><TT>indicating</TT> <BR><TT>"The URL you have dialed B...O...B is 
          not in service, please check the</TT> <BR><TT>&nbsp;URL or dial the 
          operator for assistance."</TT> <BR>&nbsp; <BR>&nbsp; 
          <P>Desired behavior 2:&nbsp; There should be a mechanism so that 
          announcements are not billable. 
          <P>Another issue that has been raised w/r/t annoucements in networks 
          where SIP signalling is billable.&nbsp; The concern is that in SIP 
          networks where 200 is used to write a start record, implementation of 
          proxy event based call diversion might generate a charge. 
          <P>Solution 2a: Play annoucements as early media <BR>One solution that 
          has been proposed is to play annoucements as early media: 
          <P>For example, recursively: 
          <BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</TT> 
          <BR><TT>|&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;&nbsp;&nbsp; 
          |</TT> <BR><TT>|--INV 
          Bob@B------&gt;|&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; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |--INV 
          Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          proxy implements&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          call forward on 404&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |--INV AnnServer------------&gt;|</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp; Diversion: 
          Bob@B&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</TT> 
          <BR><TT>|&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;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&lt;-183------------------------------------------|</TT> 
          <BR><TT>|&nbsp; Content-Disposition: 
          session&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>|&lt;==="The URL you have dialed B...O...B is 
          not==|</TT> <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check 
          the URL or dial&nbsp; |</TT> <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; the 
          operator for assistance"</TT> 
          <BR><TT>|&lt;-CANCEL---------------------------------------|</TT> 
          <BR><TT>|--200 (CANCEL)--------------------------------&gt;|</TT> 
          <P>or non-recursively: 
          <BR><TT>A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Po&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          Pt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AnnServer</TT> 
          <BR><TT>|&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;&nbsp;&nbsp; 
          |</TT> <BR><TT>|--INV 
          Bob@B------&gt;|&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; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |--INV 
          Bob@B--&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&lt;-404---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          proxy implements&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          non-recursive&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          call forward on 404&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&lt;-302-------------|&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; 
          |</TT> <BR><TT>|&nbsp; Contact: 
          AnnServer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>|&nbsp; Diversion: Bob@B; reason=404&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&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;&nbsp;&nbsp; 
          |</TT> <BR><TT>|--INV 
          AnnServer-------------------------------&gt;|</TT> <BR><TT>|&nbsp; 
          Diversion: Bob@B; reason=404&nbsp;&nbsp; 
          |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&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;&nbsp;&nbsp; 
          |</TT> 
          <BR><TT>|&lt;-183------------------------------------------|</TT> 
          <BR><TT>|&nbsp; Content-Disposition: 
          session&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          |</TT> <BR><TT>|&lt;==="The URL you have dialed B...O...B is 
          not==|</TT> <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; in service, please check 
          the URL or dial&nbsp; |</TT> <BR><TT>|&nbsp;&nbsp;&nbsp;&nbsp; the 
          operator for assistance"</TT> 
          <BR><TT>|&lt;-CANCEL---------------------------------------|</TT> 
          <BR><TT>|--200 (CANCEL)--------------------------------&gt;|</TT> 
          <P>Solution 2b: Backend billing system is aware of (non-billable) 
          Announcement Server URL <BR>Another possible solution is that the URL 
          of the AnnServer could be well-known to the backend billing system and 
          that any accounting records written connection to the AnnServer would 
          not be billed. 
          <P>I'd like to solicit others' ideas, problems, and proposed solutions 
          w/r/t annoucements in SIP. 
          <P>I'm also looking for co-authors to write an I-D w/r/t 
          announcements.&nbsp; If interested, please contact me directly at 
          byerly@cisco.com. 
          <P>thanks for your help, <BR>Bryan 
          <P>Bryan J. Byerly <BR>byerly@cisco.com <BR>&nbsp; 
        <BR>&nbsp;</P></BLOCKQUOTE></BLOCKQUOTE><BR>&nbsp;</BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C08715.D3920900--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 18:36:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11353
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 18:36:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 88D6C44368; Thu, 25 Jan 2001 17:37:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82])
	by lists.bell-labs.com (Postfix) with ESMTP id 2A36844336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 17:36:41 -0500 (EST)
Received: from cowboys (IDENT:root@localhost [127.0.0.1])
	by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id RAA08063;
	Thu, 25 Jan 2001 17:36:12 -0600
Message-ID: <001101c08727$299ad0a0$ea036e3f@dynamicsoft.com>
From: "Dean Willis" <dean.willis@softarmor.com>
To: "Connie Blanchard" <connie@ss8.com>, <sip@lists.bell-labs.com>
References: <NEBBINLBBIOMPPIEAKHGKEGKCHAA.connie@ss8.com>
Subject: Re: [SIP] adding a display name in From
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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 17:33:02 -0600
Content-Transfer-Encoding: 7bit


Yep. Kindof like ISDN.

Some of the DCS authors proposed adding an authenticated-caller header at
the proxy, using public-key mechanisms to provide for the integrity of the
header through later hops.

--
Dean

----- Original Message -----
From: "Connie Blanchard" <connie@ss8.com>
To: <sip@lists.bell-labs.com>
Sent: Thursday, January 25, 2001 12:37 PM
Subject: [SIP] adding a display name in From


> According to the SIP FAQ, Caller ID is accomplished by using the "display
> name" portion of the From header. But a proxy is not supposed to modify
the
> >From field. Does this mean that Caller ID will only be available if
> initiated from the originator of the call?
>
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
>


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 18:46:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11657
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 18:46:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 66B5D443BE; Thu, 25 Jan 2001 17:47:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17])
	by lists.bell-labs.com (Postfix) with ESMTP id A2FAF44336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 17:46:46 -0500 (EST)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-33 #42261)
 with ESMTP id <0G7Q002AASPJIO@firewall.mcit.com> for sip@lists.bell-labs.com;
 Thu, 25 Jan 2001 23:46:31 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0G7Q00E01SPHZE@dgismtp01.wcomnet.com>;
 Thu, 25 Jan 2001 23:46:31 +0000 (GMT)
Received: from Steveb1 ([166.35.224.41])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0G7Q00ADISP4PJ@dgismtp01.wcomnet.com>; Thu,
 25 Jan 2001 23:46:17 +0000 (GMT)
From: "Christopher A. Martin" <christopher.a.martin@wcom.com>
Subject: RE: [SIP] T2 and 182 Queued
In-reply-to: <Roam.SIMC.2.0.6.980457818.27647.pcalhoun@nasnfs>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Reply-To: christopher.a.martin@wcom.com
Message-id: <001c01c08728$e78b94e0$6401010a@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 17:45:30 -0600
Content-Transfer-Encoding: 7bit

> > Patrice Calhoun wrote:
> > >
> >
> > > (in any case, it sounds so much simpler to fix the
> protocol than to require
> > > firewalls)

Firewalls are a fact of life on any network providing services to the
public. The appearance of openness is merely that. Firewalls are in place
for logging, access controls, separation of the physical devices that they
protect, etc.

I dont believe that we are recommending firewalls for the end user, although
I would make the recommendation if my opinion were asked, but any
responsible service providor would implement a firewall to maintain the
integrity of the services offered.

> btw, I would venture a guess that a protocol that is
not
> subject to DoS, is
> better than a slightly faster one.
> > Thus, with a datagram protocol it is probably provably impossible to
> > prevent flooding of the server, SIP or otherwise. (DNS, for
> example, has
> > the same issue, as does any other query-response protocol.

I would hazard to say that all protocols are vulnerable to denial of service
attacks, including IPSec (for instance if enough packets are crafted and
blasted to a device running IPSec, with an incorrect encrytpion key, in a
short period of time one could exhaust the devices capability to respond to
authenticated traffic). You may prevent amplification attacks but you dont
prevent outages due to denial of service unless you implement detection for
them.

) The only
> > means to avoid the amplifier effect is to require a
> handshake (IPsec,
> > TCP, whatever) before sending more than one message.

TCP , however, is not a security mechanism as its only real job is to
provide a reliable connectionless transport.

In a way SIP is providing the same mechanism in its handshake process, TCP
waits for an acknowledgement before sending the next segment, SIP waits for
an acknowledgment before opening a media stream.

IPSec is viable on a hop by hop basis for SIP but when you get into
different realms with security policies in place the firewall would break
the IPSec traffic if NAT were enabled. Since we are talking about SIP
through IPSec on a host device may not be a bad thing, unless a denial of
service were attempted to bring down the IPSec tunnel as described above.
The issue would be administering end user keys for service networks
providing the proxy services.

>
> The only way is to require a round trip, or that every
> datagram is secured
> (see below).

It is the mechanism to detect and redirect this traffic to a different
destination such as a sandbox that will truly protect any protocol.


> > Fortunately, SIP authentication will minimize the amount of
> state, if
> > not computation.
> >
> > For SIP, the standard (basic or digest) authentication
> provides such a
> > handshake. If somebody attacks you with a non-authenticated request,
> > reject immediately with 401/407. Don't send 100 or (if under attack)
> > additional 401s. A non-malicious INVITEr will retransmit
> the INVITE if
> > the 401 got lost. This solves the multiplier problem.
> >
> > Digest already echoes back parts of the challenge, so this
> is as good as
> > the standard IPsec anti-clogging mechanism. We don't seem to know
> > anything better at this point, SIP or otherwise.
> >
> > Basic is of dubious merit, but probably the CPU effort is
> sufficiently
> > low not to matter. (The larger expense is likely to be the
> lookup of the
> > name in larger installations, not the hash comparison.)
>
> ok, so we mandate authentication. How will you
> "hgs@cs.columbia.edu" call me
> "pcalhoun@eng.sun.com"? I guess there are a couple of ways:
> 1. Mandate that a
> security relationship exists between columbia and sun
> (unlikely to happen
> soon, but possible), and require that we send SIP messages to
> our respective
> proxies instead of to each other's servers.

IMHO, yes (but thats just my opinion).

2. Mandate that we share a
> security relationship with each other's servers (even less
> likely)

Refer to Henry Sinnreich's draft,
draft-sinnreich-interdomain-sip-qos-osp-01, which goves a good example of
how this security relationship may be made possible.

 3. require
> a round trip to ensure that the request wasn't spoofed.
>
> seems like #3 above is the simplest.
>

Number three is good on a hop-by-hop basis, but requires IPSec setup between
various domain gateways (i.e., routers or firewalls), which is a matter of
trust any way you cut it. It still does not prevent the main topic of this
thread which wa prevention of DoS, as I see it.

It is often simpler for the same realm communicating over open public
address space that can administer their own equipment, but harder to gain
trust of/or even trust the many providers that may wish to interoperate.

It would seam to me that if we are talking about providers that offer SIP
services communicating with each other, it would be easier to utilize a
public PKI/Cert server. Just an idea.

In closing,
I agree that a protocol should be designed with security in mind, but at the
same time if you dont reuse the standards available for the task or even
emerging standards designed to address teh very issues it will only hinder
acceptance due to the drawbacks of making it secure and more complex, rather
than keeping it simple.

Chris Martin.


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 18:51:58 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11803
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 18:51:57 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 12048443E9; Thu, 25 Jan 2001 17:52:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16])
	by lists.bell-labs.com (Postfix) with ESMTP id C1D1044336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 17:51:30 -0500 (EST)
Received: from dgismtp01.wcomnet.com ([166.38.58.141])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0G7Q00M99SXH61@firewall.mcit.com> for sip@lists.bell-labs.com;
 Thu, 25 Jan 2001 23:51:17 +0000 (GMT)
Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com
 (PMDF V5.2-33 #42262) with SMTP id <0G7Q00H01SXGEA@dgismtp01.wcomnet.com>;
 Thu, 25 Jan 2001 23:51:16 +0000 (GMT)
Received: from Steveb1 ([166.35.224.41])
 by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262)
 with ESMTP id <0G7Q00DJDSX2PE@dgismtp01.wcomnet.com>; Thu,
 25 Jan 2001 23:51:02 +0000 (GMT)
From: "Christopher A. Martin" <christopher.a.martin@wcom.com>
Subject: RE: [SIP] T2 and 182 Queued
In-reply-to: <Roam.SIMC.2.0.6.980458043.3511.pcalhoun@nasnfs>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>
Cc: "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Reply-To: christopher.a.martin@wcom.com
Message-id: <001d01c08729$92361280$6401010a@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 17:50:16 -0600
Content-Transfer-Encoding: 7bit

I am thinkning of a more public Cert server solution that cooperate with
provider cert servers for verification rather than one providers offering,
but then that sounds like DNS heirarchy and operation, doesnt it.

But I am still doing my reading and research when it comes to cert
servers...

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Patrice Calhoun
> Sent: Thursday, January 25, 2001 3:27 PM
> To: christopher.a.martin@wcom.com
> Cc: 'Patrice Calhoun'; 'Henning G. Schulzrinne'; 'Anders Kristensen';
> 'David Frascone'; sip@lists.bell-labs.com
> Subject: RE: [SIP] T2 and 182 Queued
>
>
> > This is just an assumption on my part, but as SIP gets
> implemented as a
> > service by many providers couldn't the user receive a cert
> as part of the
> > sign up process, using the providers public certificate server.
> >
> > With this type of scenario the provideer would have
> information on file
> > about the user which is where accountability would come in.
> I am in no way
> > an authority on certificate authorities, this is just an
> thought on my part.
>
> yes you could, but then you would have to explain to your
> customers why they
> can only receive calls from people that are in your little
> boys club :)
>
> My problem is that I envisoned SIP as taking over alot of
> today's PSTN calls,
> and if this requires that every person gets a cert that has
> the same trusted
> root CA, it will take a long time.
>
> Maybe it's just my imagination :(
>
> PatC
>
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
>


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 19:05:08 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11996
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 19:05:07 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5600A443BB; Thu, 25 Jan 2001 18:05:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj_ntserver3.sj.nuera.com (h-207-20-110-62.ncal.verio.net [207.20.110.62])
	by lists.bell-labs.com (Postfix) with ESMTP id E711244336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 18:04:34 -0500 (EST)
Received: by sj_ntserver3.sj.nuera.com with Internet Mail Service (5.5.2650.21)
	id <CWGVGJ95>; Thu, 25 Jan 2001 16:04:20 -0800
Message-ID: <DD70FD1C981BD411B64400508BA547C1049E2C@sj_ntserver3.sj.nuera.com>
From: "Emami-Nouri, Mohsen" <memami@nuera.com>
To: "'Rick Dean'" <siplist@fdd.com>, "Emami-Nouri, Mohsen" <memami@nuera.com>
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] draft-ietf-sip-handoff-00pre8.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 16:04:20 -0800

Is not it the case that when the transferor receives the response to his
HANDOFF request , he can not assume with certainty that the HANDOFF was
executed successfully as opposed to REFER where the response indicates the
success or failure of REFER request. 
-----Original Message-----
From: Rick Dean [mailto:siplist@fdd.com]
Sent: Wednesday, January 24, 2001 11:21 PM
To: Emami-Nouri, Mohsen
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt



Sorry, the authors of HANDOFF don't see a 
sync vs. async issue.  With both methods 
the initial transaction completes before
the spawned request does, and both have a 
means of conveying final status.

As for a sound bite difference, we would say "scope".
HANDOFF, PhoneControl, JOIN, TAKE, and a few other
methods (hopefully never to be defined) are replaced
by REFER and a sandbox.  We believe reduced scope
and simplified syntax make HANDOFF easier to implement
and will improve compatibility.

--
Rick
3Com


On Wed, Jan 24, 2001 at 04:40:18PM -0800, Emami-Nouri, Mohsen wrote:
> Hi,
> If we were to totally summarize the difference between REFER and HANDOFF,
> would it be close if we said HANDOFF is a asynchronous and REFER is a
> synchronous call transfer model?.
> 
> -----Original Message-----
> From: Rick Dean [mailto:siplist@fdd.com]
> Sent: Wednesday, January 17, 2001 10:27 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] draft-ietf-sip-handoff-00pre8.txt
> 
> 
> 
> Dear SIP list,
> 
> Although we would like more time to 
> edit this poor draft, we feel a sneak
> peek is warranted due to its urgent nature
> with the upcomming meeting.
> 
> http://phonectl.sfour.com/draft-ietf-sip-handoff-00pre8.txt
> 
> Some significant differences from REFER are:
>   * narrower scope
>   * method completes without prompting
>   * referred-by like header generated by transferee
>   * location of headers for spawned invite
>   * error processing & final notification
> 
> Cheers,
> Rick
> rick_dean@3com.com
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 19:08:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12063
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 19:08:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B2AC4443FE; Thu, 25 Jan 2001 18:09:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 22D9F443FD
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 18:08:48 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA28294;
	Thu, 25 Jan 2001 16:08:27 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA02124;
	Thu, 25 Jan 2001 16:08:22 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA21242;
	Thu, 25 Jan 2001 16:08:12 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: RE: [SIP] T2 and 182 Queued
To: christopher.a.martin@wcom.com
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" <001c01c08728$e78b94e0$6401010a@mcit.com>
Message-ID: <Roam.SIMC.2.0.6.980467693.1196.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 16:08:13 -0800 (PST)

> Firewalls are a fact of life on any network providing services to the
> public. The appearance of openness is merely that. Firewalls are in place
> for logging, access controls, separation of the physical devices that they
> protect, etc.

I wasn't debating that firewalls don't exist, I am sitting behind one at home.
The issue is that we cannot state that a protocol is designed properly because
it can site behind a firewall. 

more below.

> I would hazard to say that all protocols are vulnerable to denial of service
> attacks, including IPSec (for instance if enough packets are crafted and
> blasted to a device running IPSec, with an incorrect encrytpion key, in a
> short period of time one could exhaust the devices capability to respond to
> authenticated traffic). You may prevent amplification attacks but you dont
> prevent outages due to denial of service unless you implement detection for
> them.

yes, and one can send 64k pings, but that's not the issue. My point is that it
is our responsibility to not create new DoS attacks. As you state, there are
plenty, so we should be adding more to the know DoS list.


> TCP , however, is not a security mechanism as its only real job is to
> provide a reliable connectionless transport.

I think that the initial message got lost in these threads. Please refer to
the original e-mail I sent on this thread. I never stated that TCP is a
security mechanism. I simply stated that TCP's handshake mechanism makes it
less susceptible to certain attacks, such as those we've already identified.

> 
> In a way SIP is providing the same mechanism in its handshake process, TCP
> waits for an acknowledgement before sending the next segment, SIP waits for
> an acknowledgment before opening a media stream.

The scenario we provided earlier allows a malicious user to fill up a queue
with bogus requests, the use of TCP makes this much more difficult. I think
that Dave also proposed another solution.

> 
> IPSec is viable on a hop by hop basis for SIP but when you get into
> different realms with security policies in place the firewall would break
> the IPSec traffic if NAT were enabled. Since we are talking about SIP
> through IPSec on a host device may not be a bad thing, unless a denial of
> service were attempted to bring down the IPSec tunnel as described above.
> The issue would be administering end user keys for service networks
> providing the proxy services.

I understand the limitations of IPSec, and I am NOT arguing against the
existing SIP authentication mechanisms (or even proposing the use of IPSec).
If IPSec can be used, hence a PKI or pre-shared key, then the same security
association can be re-used for SIP. 

I think you've misunderstood my comment.

> Refer to Henry Sinnreich's draft,
> draft-sinnreich-interdomain-sip-qos-osp-01, which goves a good example of
> how this security relationship may be made possible.

being somewhat close to AAA, I am aware how such schemes may work. But this is
really not what this thread was all about :)

> Number three is good on a hop-by-hop basis, but requires IPSec setup between
> various domain gateways (i.e., routers or firewalls), which is a matter of
> trust any way you cut it. It still does not prevent the main topic of this
> thread which wa prevention of DoS, as I see it.

Correct, so you keep implying that I'm proposing IPSec, but again, this was
not my intention. You can still use the existing SIP authentication mechanisms
even over TCP, right?

> It is often simpler for the same realm communicating over open public
> address space that can administer their own equipment, but harder to gain
> trust of/or even trust the many providers that may wish to interoperate.
> 
> It would seam to me that if we are talking about providers that offer SIP
> services communicating with each other, it would be easier to utilize a
> public PKI/Cert server. Just an idea.

Here I do agree. My point is that ALL providers would have to participate.
That will take some time. If the goal is to move everyone off of the PSTN (or
at least lots of people), then we need to consider that MANY ISPs and
corporations will be involved. That's one big PKI, and I don't see that
happening anytime soon (but again, I could be wrong).

> In closing,
> I agree that a protocol should be designed with security in mind, but at the
> same time if you dont reuse the standards available for the task or even
> emerging standards designed to address teh very issues it will only hinder
> acceptance due to the drawbacks of making it secure and more complex, rather
> than keeping it simple.

fair enough. here is my closing statement :)

I believe that it is our responsibility of ensuring that our protocols do not
introduce new DoS attacks. 

As an FYI, I am *NOT* trying to stop the development of SIP here. I actually
DO like SIP (as a call control protocol). 

PatC


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Thu Jan 25 19:18:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12254
	for <sip-archive@odin.ietf.org>; Thu, 25 Jan 2001 19:18:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8C89E443E6; Thu, 25 Jan 2001 18:19:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id 4D0AC443E6
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 18:18:28 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11472;
	Thu, 25 Jan 2001 16:18:11 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA04126;
	Thu, 25 Jan 2001 16:18:10 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA21377;
	Thu, 25 Jan 2001 16:18:05 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: RE: [SIP] T2 and 182 Queued
To: christopher.a.martin@wcom.com
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" <001d01c08729$92361280$6401010a@mcit.com>
Message-ID: <Roam.SIMC.2.0.6.980468286.22398.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Thu, 25 Jan 2001 16:18:06 -0800 (PST)

> I am thinkning of a more public Cert server solution that cooperate with
> provider cert servers for verification rather than one providers offering,
> but then that sounds like DNS heirarchy and operation, doesnt it.

Unfortunately, that's not *quite* the way it works. However, it is possible
for multiple corporations to have their own certificate repository, and only
dish out their own certs (and, of course, CRLs). However, for everyone across
domains to trust each other, they can either co-sign everyone's cert (not
going to happen), or find a trusted root to sign their certs (more likely). 

One problem, of course, is that CA are typically disconnected from the
network, and have plenty of physical security. Not one would expect from a
public (or free) service.

One interesting side effect with PKIs, is that the argument of speed (hence
the reason for using datagrams) is eliminated when users need to find
certificate servers for a domain, retrieve the certificate, validate the
certificate authority chain (which requires retrieving additional
certificates), and checking against the CRL.

However, I am sure that someone such as Verisign would be most accomodating in
becoming the root server :)

> 
> But I am still doing my reading and research when it comes to cert
> servers...

Aren't we all :(

PatC


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 00:58:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18531
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 00:58:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 812404433E; Thu, 25 Jan 2001 23:59:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cybertron.div8.net (HSE-Kitchener-ppp194187.sympatico.ca [64.229.12.28])
	by lists.bell-labs.com (Postfix) with ESMTP id 859EE44336
	for <sip@lists.bell-labs.com>; Thu, 25 Jan 2001 23:58:05 -0500 (EST)
Received: by div8.net
	via sendmail from stdin
	id <m14M1vX-003ErcC@cybertron.div8.net> (Debian Smail3.2.0.102)
	for sip@lists.bell-labs.com; Fri, 26 Jan 2001 01:00:03 -0500 (EST) 
From: Billy Biggs <billy@billybiggs.com>
To: "Emami-Nouri, Mohsen" <memami@nuera.com>
Cc: Rick Dean <siplist@fdd.com>, SIP List <sip@lists.bell-labs.com>
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
Message-ID: <20010126010003.A1005@div8.net>
References: <DD70FD1C981BD411B64400508BA547C1049E2C@sj_ntserver3.sj.nuera.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <DD70FD1C981BD411B64400508BA547C1049E2C@sj_ntserver3.sj.nuera.com>; from memami@nuera.com on Thu, Jan 25, 2001 at 04:04:20PM -0800
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 01:00:03 -0500

Emami-Nouri, Mohsen (memami@nuera.com):

> Is not it the case that when the transferor receives the response to
> his HANDOFF request , he can not assume with certainty that the
> HANDOFF was executed successfully as opposed to REFER where the
> response indicates the success or failure of REFER request. 

  As it turns out, REFER is being redrafted to have the REFER
transaction complete immediately upon acceptance of the request rather
than success or failure of the action.  So, in this respect they are
identical.

> -----Original Message-----
> From: Rick Dean [mailto:siplist@fdd.com]
> Sent: Wednesday, January 24, 2001 11:21 PM
> To: Emami-Nouri, Mohsen
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
> 
> Sorry, the authors of HANDOFF don't see a 
> sync vs. async issue.  With both methods 
> the initial transaction completes before
> the spawned request does, and both have a 
> means of conveying final status.
> 
> As for a sound bite difference, we would say "scope".
> HANDOFF, PhoneControl, JOIN, TAKE, and a few other
> methods (hopefully never to be defined) are replaced
> by REFER and a sandbox.  We believe reduced scope
> and simplified syntax make HANDOFF easier to implement
> and will improve compatibility.
> 
> --
> Rick
> 3Com
> 
> 
> On Wed, Jan 24, 2001 at 04:40:18PM -0800, Emami-Nouri, Mohsen wrote:
> > Hi,
> > If we were to totally summarize the difference between REFER and HANDOFF,
> > would it be close if we said HANDOFF is a asynchronous and REFER is a
> > synchronous call transfer model?.
> > 
> > -----Original Message-----
> > From: Rick Dean [mailto:siplist@fdd.com]
> > Sent: Wednesday, January 17, 2001 10:27 AM
> > To: sip@lists.bell-labs.com
> > Subject: [SIP] draft-ietf-sip-handoff-00pre8.txt
> > 
> > 
> > 
> > Dear SIP list,
> > 
> > Although we would like more time to 
> > edit this poor draft, we feel a sneak
> > peek is warranted due to its urgent nature
> > with the upcomming meeting.
> > 
> > http://phonectl.sfour.com/draft-ietf-sip-handoff-00pre8.txt
> > 
> > Some significant differences from REFER are:
> >   * narrower scope
> >   * method completes without prompting
> >   * referred-by like header generated by transferee
> >   * location of headers for spawned invite
> >   * error processing & final notification
> > 
> > Cheers,
> > Rick
> > rick_dean@3com.com
> > 
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.

-- 
Billy Biggs                     bbiggs@dumbterm.net
http://www.billybiggs.com/      wbiggs@uwaterloo.ca

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 11:46:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14252
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 11:46:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 309D844340; Fri, 26 Jan 2001 10:47:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 1D5F744336
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 10:46:09 -0500 (EST)
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0G7S00C1K3WJV9@firewall.mcit.com> for sip@lists.bell-labs.com;
 Fri, 26 Jan 2001 16:45:55 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with SMTP id <0G7S00I013W8ZI@dgismtp02.wcomnet.com>;
 Fri, 26 Jan 2001 16:45:53 +0000 (GMT)
Received: from Steveb1 ([166.35.224.41])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0G7S00I183W7WW@dgismtp02.wcomnet.com>; Fri,
 26 Jan 2001 16:45:43 +0000 (GMT)
From: "Christopher A. Martin" <christopher.a.martin@wcom.com>
Subject: RE: [SIP] T2 and 182 Queued
In-reply-to: <Roam.SIMC.2.0.6.980457818.27647.pcalhoun@nasnfs>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>
Cc: "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Reply-To: christopher.a.martin@wcom.com
Message-id: <001001c087b7$5309f3e0$6401010a@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 10:44:59 -0600
Content-Transfer-Encoding: 7bit



> > Patrice Calhoun wrote:
> ok, but I wasn't talking about adding IPSec.
>
> btw, I would venture a guess that a protocol that is not
> subject to DoS, is
> better than a slightly faster one.

This is true, and as you mentioned in an earlier email, I may have addressed
more than one email with my last few responses. I wasnt trying to imply that
you were talking about adding IPSec, merely agreeing that it is a viable
solution, although limiting.

Thats what heppens when I dont find the first email in a thread and answer
in the middle of it.  :^)

Chris


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 11:52:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14458
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 11:52:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 061334434E; Fri, 26 Jan 2001 10:53:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 75AC144336
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 10:52:07 -0500 (EST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA12508;
	Fri, 26 Jan 2001 08:52:05 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAR04123;
	Fri, 26 Jan 2001 08:51:53 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA27769; Fri, 26 Jan 2001 08:51:52 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14961.43816.731929.616538@thomasm-u1.cisco.com>
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: christopher.a.martin@wcom.com,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] T2 and 182 Queued
In-Reply-To: <Roam.SIMC.2.0.6.980455149.5856.pcalhoun@nasnfs>
References: <000d01c0870c$bf543ca0$6401010a@mcit.com>
	<Roam.SIMC.2.0.6.980455149.5856.pcalhoun@nasnfs>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 08:51:52 -0800 (PST)
Content-Transfer-Encoding: 7bit

Patrice Calhoun writes:
 > > A global PKI would seem to be a natural progression if implemented at the
 > > firewall level, when speaking of server complexes, and one that I would like
 > > to see pursued. Once authenticated to the firewall one could "assume" a
 > > minimal level of end-to-end security/accountability or "trust" in relation
 > > to SIP communications.
 > 
 > Putting a cert on the SIP server is a quarter (or even less) of the problem.
 > The issue then is to distribute certificates with ANYONE that will communicate
 > with your SIP server (and I DO mean anyone!). If my grand-mother wants to call
 > you, must she first go to her favorite PKI vendor and get a signed cert?

   False. PKCROSS is your friend.

		  Mike

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 11:55:59 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14563
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 11:55:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1D03F44355; Fri, 26 Jan 2001 10:56:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id DF08044355
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 10:55:18 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08161;
	Fri, 26 Jan 2001 08:54:57 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17781;
	Fri, 26 Jan 2001 08:54:56 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA29706;
	Fri, 26 Jan 2001 08:54:53 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: RE: [SIP] T2 and 182 Queued
To: Michael Thomas <mat@cisco.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        christopher.a.martin@wcom.com,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" <14961.43816.731929.616538@thomasm-u1.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.980528093.13390.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 08:54:53 -0800 (PST)

> Patrice Calhoun writes:
>  > > A global PKI would seem to be a natural progression if implemented at
> the
>  > > firewall level, when speaking of server complexes, and one that I would
> like
>  > > to see pursued. Once authenticated to the firewall one could "assume" a
>  > > minimal level of end-to-end security/accountability or "trust" in
> relation
>  > > to SIP communications.
>  > 
>  > Putting a cert on the SIP server is a quarter (or even less) of the
> problem.
>  > The issue then is to distribute certificates with ANYONE that will
> communicate
>  > with your SIP server (and I DO mean anyone!). If my grand-mother wants to
> call
>  > you, must she first go to her favorite PKI vendor and get a signed cert?
> 
>    False. PKCROSS is your friend.
> 

ok, I assume this is KINK (and I have no idea what's going on in KINK). So
this only requires a global Kerberos infrastructure (meaning all kerberos
servers trust each other), and all users must be registered with their local
Kerberos server. Is this correct?

(again, I don't see how this has ANYTHING to do with the original thread,
where I pointed out a potential DoS flaw, and requested some help from the WG
to see how this could be closed).

PatC


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 12:04:59 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14876
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 12:04:59 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 693AD4435D; Fri, 26 Jan 2001 11:05:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by lists.bell-labs.com (Postfix) with ESMTP id B7E0B4435C
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 11:04:31 -0500 (EST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id JAA00456;
	Fri, 26 Jan 2001 09:03:49 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAR04179;
	Fri, 26 Jan 2001 09:03:46 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA27772; Fri, 26 Jan 2001 09:03:46 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14961.44530.289344.512637@thomasm-u1.cisco.com>
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        christopher.a.martin@wcom.com,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
In-Reply-To: <3A7092A2.21DD6514@cs.columbia.edu>
References: <Roam.SIMC.2.0.6.980455149.5856.pcalhoun@nasnfs>
	<3A7092A2.21DD6514@cs.columbia.edu>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 09:03:46 -0800 (PST)
Content-Transfer-Encoding: 7bit

Henning G. Schulzrinne writes:
 > Suggestions are welcome, but I would guess that any such fix will
 > increase the message complexity of the non-DoS case and thus reduce
 > overall throughput. For example, use of TCP and IPsec definitely will,
 > due to the extra round-trip times and TCP-level messages.

   I assume you're mainly talking about the UA-UA traffic
   which assumes no previous communication, in which case
   I agree. However UA->proxy, proxy-proxy, etc will
   likely benefit from caching affects of keeping the SA's
   up for some potentially indefinite time.

 > All TCP SYN flood mechanisms simply minimize the amount of state that is
 > committed on the server prior to completion of the handshake.
 > Fortunately, SIP authentication will minimize the amount of state, if
 > not computation.

   If I had to pick my poison, I'd rather get hopwise
   crypto and strong authentication out of the overhead.
   
 > For SIP, the standard (basic or digest) authentication provides such a
 > handshake. If somebody attacks you with a non-authenticated request,
 > reject immediately with 401/407. Don't send 100 or (if under attack)
 > additional 401s. A non-malicious INVITEr will retransmit the INVITE if
 > the 401 got lost. This solves the multiplier problem.

   Not really. Basic can easily be replayed, and digest
   can as well, assuming that you're using the commonly
   instantiated version which doesn't run a MAC over
   the whole message with a new nonce for each message.
   I assume that you'd consider per message challenges
   unacceptible overhead.
   
		Mike

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 12:13:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15179
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 12:13:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 18FDD44361; Fri, 26 Jan 2001 11:14:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 8CAD044361
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 11:13:50 -0500 (EST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id JAA08756;
	Fri, 26 Jan 2001 09:13:38 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAR04210;
	Fri, 26 Jan 2001 09:13:34 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA27775; Fri, 26 Jan 2001 09:13:34 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14961.45118.188905.521549@thomasm-u1.cisco.com>
To: christopher.a.martin@wcom.com
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] T2 and 182 Queued
In-Reply-To: <001c01c08728$e78b94e0$6401010a@mcit.com>
References: <Roam.SIMC.2.0.6.980457818.27647.pcalhoun@nasnfs>
	<001c01c08728$e78b94e0$6401010a@mcit.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 09:13:34 -0800 (PST)
Content-Transfer-Encoding: 7bit

Christopher A. Martin writes:
 > I would hazard to say that all protocols are vulnerable to denial of service
 > attacks, including IPSec (for instance if enough packets are crafted and
 > blasted to a device running IPSec, with an incorrect encrytpion key, in a
 > short period of time one could exhaust the devices capability to respond to
 > authenticated traffic). You may prevent amplification attacks but you dont
 > prevent outages due to denial of service unless you implement detection for
 > them.

   Correct. However, IPsec/TLS/etc -- other than
   queuing of packets -- does not create state or
   lead to amplification attacks. Unless you are
   concerned with attacks from within (ie, an
   authenticated user trying to do the deed), 
   IPsec and its kin can only be slagged only by a
   brute force attack which is, I suspect, the best
   you can hope for with DoS.

 > IPSec is viable on a hop by hop basis for SIP but when you get into
 > different realms with security policies in place the firewall would break
 > the IPSec traffic if NAT were enabled. 

   Then you have to live with ALG's (proxies,
   B2BUA's). This is an artifact of NAT and
   firewalls and is not specific to SIP.


		    Mike

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 12:31:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15726
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 12:31:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B970144354; Fri, 26 Jan 2001 11:32:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 9AE814434D
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 11:31:39 -0500 (EST)
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0G7S0096W5ZUT5@firewall.mcit.com> for sip@lists.bell-labs.com;
 Fri, 26 Jan 2001 17:31:07 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with SMTP id <0G7S00M015ZIIB@dgismtp02.wcomnet.com>;
 Fri, 26 Jan 2001 17:31:06 +0000 (GMT)
Received: from Steveb1 ([166.35.224.41])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0G7S00L2C5ZEY9@dgismtp02.wcomnet.com>; Fri,
 26 Jan 2001 17:30:51 +0000 (GMT)
From: "Christopher A. Martin" <christopher.a.martin@wcom.com>
Subject: RE: [SIP] T2 and 182 Queued
In-reply-to: <14961.45118.188905.521549@thomasm-u1.cisco.com>
To: "'Michael Thomas'" <mat@cisco.com>
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Reply-To: christopher.a.martin@wcom.com
Message-id: <001101c087bd$a03e9ac0$6401010a@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 11:30:05 -0600
Content-Transfer-Encoding: 7bit

Michael Thomas writes,
>  > IPSec is viable on a hop by hop basis for SIP but when you get into
>  > different realms with security policies in place the
> firewall would break
>  > the IPSec traffic if NAT were enabled.
>
>    Then you have to live with ALG's (proxies,
>    B2BUA's). This is an artifact of NAT and
>    firewalls and is not specific to SIP.
>
>
> 		    Mike
True, after all firewalls are supposed to be implemented to satisfy the
needs of the protocol and not the other way around.

From my point of reference to clear up where I am coming from, I am speaking
from a b2b type scenario where the above may be the case, rather than a
public scenario.

Henning G. Schulzrinne writes:
 > For SIP, the standard (basic or digest) authentication provides such a
 > handshake. If somebody attacks you with a non-authenticated request,
 > reject immediately with 401/407. Don't send 100 or (if under attack)
 > additional 401s. A non-malicious INVITEr will retransmit the INVITE if
 > the 401 got lost. This solves the multiplier problem.
Mikael Thomas writes:
 >  Not really. Basic can easily be replayed, and digest
 >  can as well, assuming that you're using the commonly
 >  instantiated version which doesn't run a MAC over
 >  the whole message with a new nonce for each message.
 >  I assume that you'd consider per message challenges
 >  unacceptible overhead.

I would like to see some method that results in the public UA wishing to
communicate with a private UA, via proxies, firewalls, gateways, which has a
form of accountability built inwhich prevents the abuses that can be
performed when hash or digest are implemented, which is why I brought up
some form of PKI or certificate server scenario. As it is, authentication
from what I have seen in call flows, only occurs during the intial invite to
a proxy, in such a scenario using UA to Proxy to UA.

You mentioned PKCROSS earlier, I think I will look into this.

Thanks,
Chris


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 12:34:31 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15816
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 12:34:31 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A93A04436C; Fri, 26 Jan 2001 11:34:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 7BC1E4434D
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 11:33:40 -0500 (EST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA10209;
	Fri, 26 Jan 2001 09:33:40 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAR04292;
	Fri, 26 Jan 2001 09:33:24 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA27780; Fri, 26 Jan 2001 09:33:24 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14961.46308.371178.78038@thomasm-u1.cisco.com>
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: Michael Thomas <mat@cisco.com>, christopher.a.martin@wcom.com,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] T2 and 182 Queued
In-Reply-To: <Roam.SIMC.2.0.6.980528093.13390.pcalhoun@nasnfs>
References: <14961.43816.731929.616538@thomasm-u1.cisco.com>
	<Roam.SIMC.2.0.6.980528093.13390.pcalhoun@nasnfs>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 09:33:24 -0800 (PST)
Content-Transfer-Encoding: 7bit

Patrice Calhoun writes:
 > ok, I assume this is KINK (and I have no idea what's going on in KINK). So
 > this only requires a global Kerberos infrastructure (meaning all kerberos
 > servers trust each other), and all users must be registered with their local
 > Kerberos server. Is this correct?

   KINK is orthogonal to PKCROSS. The statement was that the
   only way to have a PKI was to have everybody get a certificate.
   This is not the case. PKCROSS allows the PKI to be scaled at
   the level of the KDC, not the user. Users may or may not use
   certs to do their initial authentication. This allows the PKI
   requirements of certs with cross realm trust implications to 
   be scaled down 3-5 orders of magnitude. Maybe more.

 > (again, I don't see how this has ANYTHING to do with the original thread,
 > where I pointed out a potential DoS flaw, and requested some help from the WG
 > to see how this could be closed).

   The assertion was made -- repeatedly -- that base level
   crypto was not a feasible and/or deployable mitigation
   for DoS attacks for a variety of reasons. Given this 
   false premise, serveral people think that we ought to
   do all sort of horrendous things to SIP to prevent the
   myriad of ways that SIP allows an unauthenticated and/or
   spoofed user to cause state, etc, to be stored on the
   device under attack. Unlike TCP which has a relatively 
   simple state machine, SIP probably has hundreds of
   these opportunities and each would need to be painstakingly
   weighed with DoS opportunity vs. performance/complexity
   in mind. I see absolutely no reason for optimism here.

   This alone -- not to mention that crypto gives lot of
   other benefits -- sounds like a far more tractable
   solution for SIP. 

		Mike
   

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 12:42:04 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16024
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 12:42:04 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0B90744374; Fri, 26 Jan 2001 11:42:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 048B144373
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 11:41:06 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24751;
	Fri, 26 Jan 2001 09:40:28 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04464;
	Fri, 26 Jan 2001 09:40:23 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA00547;
	Fri, 26 Jan 2001 09:40:11 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: RE: [SIP] T2 and 182 Queued
To: Michael Thomas <mat@cisco.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        christopher.a.martin@wcom.com,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" <14961.46308.371178.78038@thomasm-u1.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.980530811.5742.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 09:40:11 -0800 (PST)

>  > (again, I don't see how this has ANYTHING to do with the original thread,
>  > where I pointed out a potential DoS flaw, and requested some help from
> the WG
>  > to see how this could be closed).
> 
>    The assertion was made -- repeatedly -- that base level
>    crypto was not a feasible and/or deployable mitigation
>    for DoS attacks for a variety of reasons. Given this 
>    false premise, serveral people think that we ought to
>    do all sort of horrendous things to SIP to prevent the
>    myriad of ways that SIP allows an unauthenticated and/or
>    spoofed user to cause state, etc, to be stored on the
>    device under attack. Unlike TCP which has a relatively 
>    simple state machine, SIP probably has hundreds of
>    these opportunities and each would need to be painstakingly
>    weighed with DoS opportunity vs. performance/complexity
>    in mind. I see absolutely no reason for optimism here.
> 
>    This alone -- not to mention that crypto gives lot of
>    other benefits -- sounds like a far more tractable
>    solution for SIP. 

OK, as I mentioned, I was open to other solutions other than requiring
TCP, as long as they worked.

So, if I am to understand, authentication in SIP is mandatory and schemes that
do not provide replay protection are not supported, correct?

PatC


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 12:55:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16253
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 12:55:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7B52344366; Fri, 26 Jan 2001 11:56:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id EBB0D4435C
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 11:55:56 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 26 Jan 2001 17:55:44 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id RAA27021; Fri, 26 Jan 2001 17:50:50 GMT
Message-ID: <3A71B8FA.A888C474@ubiquity.net>
From: James Undery <jundery@ubiquity.net>
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: Michael Thomas <mat@cisco.com>, christopher.a.martin@wcom.com,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
References: <Roam.SIMC.2.0.6.980530811.5742.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 17:50:50 +0000
Content-Transfer-Encoding: 7bit



Patrice Calhoun wrote:

> OK, as I mentioned, I was open to other solutions other than requiring
> TCP, as long as they worked.

TCP is not a solution I could just as easily DoS your server with TCP. If you
totally remove UDP from the spec it may require a DDoS but it is still possible
for a person to produce a script kiddie simple program to take out a SIP server if
TCP is your only protection. The solution I feel lies out side the scope of RFC
2543 and its successors and in proper network configuration using IPSec,
firewalls, routers et al where appropriate.

James Undery


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 13:00:00 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16352
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 12:59:59 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 783454437B; Fri, 26 Jan 2001 12:00:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 695854436B
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 11:59:54 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03056;
	Fri, 26 Jan 2001 09:59:06 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08882;
	Fri, 26 Jan 2001 09:58:43 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA00846;
	Fri, 26 Jan 2001 09:58:40 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: Re: [SIP] T2 and 182 Queued
To: James Undery <jundery@ubiquity.net>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        Michael Thomas <mat@cisco.com>, christopher.a.martin@wcom.com,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" <3A71B8FA.A888C474@ubiquity.net>
Message-ID: <Roam.SIMC.2.0.6.980531920.30884.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 09:58:40 -0800 (PST)

> 
> 
> Patrice Calhoun wrote:
> 
> > OK, as I mentioned, I was open to other solutions other than requiring
> > TCP, as long as they worked.
> 
> TCP is not a solution I could just as easily DoS your server with TCP. If you
> totally remove UDP from the spec it may require a DDoS but it is still
> possible for a person to produce a script kiddie simple program to take out
> a SIP server if TCP is your only protection. The solution I feel lies out
> side the scope of RFC 2543 and its successors and in proper network
> configuration using IPSec, firewalls, routers et al where appropriate.

sigh. seems like we are going around in circles....

TCP provides protection against the attacks Dave and I mentioned, namely
spoofed source IP address. Since TCP does require the 3 way handshake, it
would be VERY difficult for a hacker to mount a successful SIP attack.

But, as you state, TCP can still be attacked, but these attacks are better
known, and many operating systems, routers and firewalls already have
protection against the known ones.

so, to restate my (and the position from IESG and their security advisors)
position, is that protocols MUST NOT introduce "new attacks".

Once more I state (and did so in the e-mail you replied to) that mandating
authentication is a workable solution. My question was whether we could
mandate a non-replayable authentication scheme for all SIP messages.

PatC


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 13:09:25 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16598
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 13:09:25 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1000C44394; Fri, 26 Jan 2001 12:03:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16])
	by lists.bell-labs.com (Postfix) with ESMTP id 3AF0C44391
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 12:02:01 -0500 (EST)
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-33 #42260)
 with ESMTP id <0G7S00G7G7DW3Q@firewall.mcit.com> for sip@lists.bell-labs.com;
 Fri, 26 Jan 2001 18:01:09 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with SMTP id <0G7S00G017DQFO@dgismtp02.wcomnet.com>;
 Fri, 26 Jan 2001 18:01:08 +0000 (GMT)
Received: from Steveb1 ([166.35.224.41])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0G7S00ADQ7DJG5@dgismtp02.wcomnet.com>; Fri,
 26 Jan 2001 18:00:55 +0000 (GMT)
From: "Christopher A. Martin" <christopher.a.martin@wcom.com>
Subject: RE: [SIP] T2 and 182 Queued
In-reply-to: <Roam.SIMC.2.0.6.980530811.5742.pcalhoun@nasnfs>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        "'Michael Thomas'" <mat@cisco.com>
Cc: "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Reply-To: christopher.a.martin@wcom.com
Message-id: <001401c087c1$d3da2260$6401010a@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 12:00:10 -0600
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com]
> Sent: Friday, January 26, 2001 11:40 AM
> To: Michael Thomas
> Cc: Patrice Calhoun; christopher.a.martin@wcom.com; 'Henning G.
> Schulzrinne'; 'Anders Kristensen'; 'David Frascone';
> sip@lists.bell-labs.com
> Subject: RE: [SIP] T2 and 182 Queued
>
>
> >  > (again, I don't see how this has ANYTHING to do with the
> original thread,
> >  > where I pointed out a potential DoS flaw, and requested
> some help from
> > the WG
> >  > to see how this could be closed).
> >
> >    The assertion was made -- repeatedly -- that base level
> >    crypto was not a feasible and/or deployable mitigation
> >    for DoS attacks for a variety of reasons. Given this
> >    false premise, serveral people think that we ought to
> >    do all sort of horrendous things to SIP to prevent the
> >    myriad of ways that SIP allows an unauthenticated and/or
> >    spoofed user to cause state, etc, to be stored on the
> >    device under attack. Unlike TCP which has a relatively
> >    simple state machine, SIP probably has hundreds of
> >    these opportunities and each would need to be painstakingly
> >    weighed with DoS opportunity vs. performance/complexity
> >    in mind. I see absolutely no reason for optimism here.
> >
> >    This alone -- not to mention that crypto gives lot of
> >    other benefits -- sounds like a far more tractable
> >    solution for SIP.
>
> OK, as I mentioned, I was open to other solutions other than requiring
> TCP, as long as they worked.
>
> So, if I am to understand, authentication in SIP is mandatory
> and schemes that
> do not provide replay protection are not supported, correct?
I would disagree with this, and I know that you do to, replay prevention
needs to be implementd at some level, like at the provider level, not the
edge. Security should be a multilayered beast in the IP world.

>
> PatC
>


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 13:13:09 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16679
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 13:13:09 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6A97744398; Fri, 26 Jan 2001 12:06:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 2C45B44398
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 12:05:33 -0500 (EST)
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0G7S0022P7KS3F@firewall.mcit.com> for sip@lists.bell-labs.com;
 Fri, 26 Jan 2001 18:05:16 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with SMTP id <0G7S00I017KMHZ@dgismtp02.wcomnet.com>;
 Fri, 26 Jan 2001 18:05:15 +0000 (GMT)
Received: from Steveb1 ([166.35.224.41])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0G7S00I067KGGY@dgismtp02.wcomnet.com>; Fri,
 26 Jan 2001 18:05:05 +0000 (GMT)
From: "Christopher A. Martin" <christopher.a.martin@wcom.com>
Subject: RE: [SIP] T2 and 182 Queued
In-reply-to: <3A71B8FA.A888C474@ubiquity.net>
To: "'James Undery'" <jundery@ubiquity.net>,
        "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>
Cc: "'Michael Thomas'" <mat@cisco.com>,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Reply-To: christopher.a.martin@wcom.com
Message-id: <001701c087c2$68b6f5c0$6401010a@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 12:04:20 -0600
Content-Transfer-Encoding: 7bit

> Patrice Calhoun wrote:
> 
> > OK, as I mentioned, I was open to other solutions other 
> than requiring
> > TCP, as long as they worked.
> 
> TCP is not a solution I could just as easily DoS your server 
> with TCP. If you
> totally remove UDP from the spec it may require a DDoS but it 
> is still possible
> for a person to produce a script kiddie simple program to 
> take out a SIP server if
> TCP is your only protection. The solution I feel lies out 
> side the scope of RFC
> 2543 and its successors and in proper network configuration 
> using IPSec,
> firewalls, routers et al where appropriate.
> 
> James Undery
>

True, and this at an interdomain and/or core level where necessary. 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 13:16:11 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16737
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 13:16:09 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EA3BE4438A; Fri, 26 Jan 2001 12:07:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id DB0BB44389
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 12:06:48 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05342;
	Fri, 26 Jan 2001 10:06:22 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10679;
	Fri, 26 Jan 2001 10:06:21 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA01030;
	Fri, 26 Jan 2001 10:06:02 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: RE: [SIP] T2 and 182 Queued
To: christopher.a.martin@wcom.com
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        "'Michael Thomas'" <mat@cisco.com>,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" <001401c087c1$d3da2260$6401010a@mcit.com>
Message-ID: <Roam.SIMC.2.0.6.980532362.9876.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 10:06:02 -0800 (PST)


> > So, if I am to understand, authentication in SIP is mandatory
> > and schemes that
> > do not provide replay protection are not supported, correct?

> I would disagree with this, and I know that you do to, replay prevention
> needs to be implementd at some level, like at the provider level, not the
> edge. Security should be a multilayered beast in the IP world.

Sorry, the above doesn't parse :)

I do not disagree with myself, I was actually being honest. If some level of
authentication is required, then an additional replay protection method MUST
be enforced. This could be done through timestamps, nonces (which are
patented, btw), or other mechanisms. Either way, I don't see how providers
guarantee replay protection (or even why I would trust some unknown entity to
provide replay protection).

PatC


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 13:19:07 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16867
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 13:19:06 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 39AF44438F; Fri, 26 Jan 2001 12:09:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 483604438E
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 12:08:58 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA01593;
	Fri, 26 Jan 2001 13:07:32 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9K2YMA>; Fri, 26 Jan 2001 13:01:14 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB1F0@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        James Undery <jundery@ubiquity.net>
Cc: Michael Thomas <mat@cisco.com>, christopher.a.martin@wcom.com,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        Anders Kristensen <Akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] T2 and 182 Queued
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 13:01:09 -0500



 

> -----Original Message-----
> From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com]
> Sent: Friday, January 26, 2001 12:59 PM
> To: James Undery
> Cc: Patrice Calhoun; Michael Thomas; christopher.a.martin@wcom.com;
> 'Henning G. Schulzrinne'; 'Anders Kristensen'; 'David Frascone';
> sip@lists.bell-labs.com
> Subject: Re: [SIP] T2 and 182 Queued
> 
> 
> > 
> > 
> > Patrice Calhoun wrote:
> > 
> > > OK, as I mentioned, I was open to other solutions other 
> than requiring
> > > TCP, as long as they worked.
> > 
> > TCP is not a solution I could just as easily DoS your 
> server with TCP. If you
> > totally remove UDP from the spec it may require a DDoS but 
> it is still
> > possible for a person to produce a script kiddie simple 
> program to take out
> > a SIP server if TCP is your only protection. The solution I 
> feel lies out
> > side the scope of RFC 2543 and its successors and in proper network
> > configuration using IPSec, firewalls, routers et al where 
> appropriate.
> 
> sigh. seems like we are going around in circles....
> 
> TCP provides protection against the attacks Dave and I 
> mentioned, namely
> spoofed source IP address. Since TCP does require the 3 way 
> handshake, it
> would be VERY difficult for a hacker to mount a successful SIP attack.
> 
> But, as you state, TCP can still be attacked, but these 
> attacks are better
> known, and many operating systems, routers and firewalls already have
> protection against the known ones.
> 
> so, to restate my (and the position from IESG and their 
> security advisors)
> position, is that protocols MUST NOT introduce "new attacks".
> 
> Once more I state (and did so in the e-mail you replied to) 
> that mandating
> authentication is a workable solution. My question was 
> whether we could
> mandate a non-replayable authentication scheme for all SIP messages.
> 
> PatC
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 13:22:21 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16925
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 13:22:20 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 37137443A8; Fri, 26 Jan 2001 12:14:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2])
	by lists.bell-labs.com (Postfix) with ESMTP id EA136443AC
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 12:11:20 -0500 (EST)
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-32 #42257)
 with ESMTP id <0G7S0040F7UGT3@firewall.mcit.com> for sip@lists.bell-labs.com;
 Fri, 26 Jan 2001 18:11:04 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with SMTP id <0G7S00L017U9PR@dgismtp02.wcomnet.com>;
 Fri, 26 Jan 2001 18:11:04 +0000 (GMT)
Received: from Steveb1 ([166.35.224.41])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0G7S00J6C7U1W0@dgismtp02.wcomnet.com>; Fri,
 26 Jan 2001 18:10:50 +0000 (GMT)
From: "Christopher A. Martin" <christopher.a.martin@wcom.com>
Subject: RE: [SIP] T2 and 182 Queued
In-reply-to: <Roam.SIMC.2.0.6.980531920.30884.pcalhoun@nasnfs>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        "'James Undery'" <jundery@ubiquity.net>
Cc: "'Michael Thomas'" <mat@cisco.com>,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Reply-To: christopher.a.martin@wcom.com
Message-id: <001801c087c3$363e5100$6401010a@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 12:10:05 -0600
Content-Transfer-Encoding: 7bit


> > Patrice Calhoun wrote:
> >
> > > OK, as I mentioned, I was open to other solutions other
> than requiring
> > > TCP, as long as they worked.
> >
> > TCP is not a solution I could just as easily DoS your
> server with TCP. If you
> > totally remove UDP from the spec it may require a DDoS but
> it is still
> > possible for a person to produce a script kiddie simple
> program to take out
> > a SIP server if TCP is your only protection. The solution I
> feel lies out
> > side the scope of RFC 2543 and its successors and in proper network
> > configuration using IPSec, firewalls, routers et al where
> appropriate.
>
> sigh. seems like we are going around in circles....
>
> TCP provides protection against the attacks Dave and I
> mentioned, namely
> spoofed source IP address. Since TCP does require the 3 way
> handshake, it
> would be VERY difficult for a hacker to mount a successful SIP attack.

Actually tcp does not prevent spoofing the source IP address. There are
hijack utilities in use today that perform this very task, and TCP is the
vulnerability exploited in these attacks, some of them do this by guessing
the TCP sequence numbers, others do it another way.

IPSec is the only real method to prevent spoofing and replay attacks.

>
> But, as you state, TCP can still be attacked, but these
> attacks are better
> known, and many operating systems, routers and firewalls already have
> protection against the known ones.
>
> so, to restate my (and the position from IESG and their
> security advisors)
> position, is that protocols MUST NOT introduce "new attacks".
>
> Once more I state (and did so in the e-mail you replied to)
> that mandating
> authentication is a workable solution. My question was
> whether we could
> mandate a non-replayable authentication scheme for all SIP messages.
>
I agree with this, we do need to mandate this type of scheme, but I believe
that a non replayable mechanism would not be digest or hash authentication,
rather PGP or possibly S/Mime may offer this level of protection.

> PatC
>


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 13:26:46 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16992
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 13:26:45 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 499E344389; Fri, 26 Jan 2001 12:20:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1])
	by lists.bell-labs.com (Postfix) with ESMTP id E10BD44386
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 12:19:31 -0500 (EST)
Received: from dgismtp02.wcomnet.com ([166.38.58.142])
 by firewall.mcit.com (PMDF V5.2-32 #42256)
 with ESMTP id <0G7S0081I884CE@firewall.mcit.com> for sip@lists.bell-labs.com;
 Fri, 26 Jan 2001 18:19:17 +0000 (GMT)
Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com
 (PMDF V5.2-33 #42263) with SMTP id <0G7S00301880IP@dgismtp02.wcomnet.com>;
 Fri, 26 Jan 2001 18:19:16 +0000 (GMT)
Received: from Steveb1 ([166.35.224.41])
 by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263)
 with ESMTP id <0G7S00IIG87U7K@dgismtp02.wcomnet.com>; Fri,
 26 Jan 2001 18:19:06 +0000 (GMT)
From: "Christopher A. Martin" <christopher.a.martin@wcom.com>
Subject: RE: [SIP] T2 and 182 Queued
In-reply-to: <Roam.SIMC.2.0.6.980532362.9876.pcalhoun@nasnfs>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>
Cc: "'Michael Thomas'" <mat@cisco.com>,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Reply-To: christopher.a.martin@wcom.com
Message-id: <001901c087c4$5e439100$6401010a@mcit.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 12:18:21 -0600
Content-Transfer-Encoding: 7bit

Its all about trust.  :^)

If along the way, during the TCP handshake someone were to decide to
takeover, from the TCP ACK, by hijacking the session, how would this be
prevented by the authentication methods supplied with SIP to date(not
including PGP in this statement, which would be many levels better than
digest and hash), TCP or not?

Chris.

> -----Original Message-----
> From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com]
> Sent: Friday, January 26, 2001 12:06 PM
> To: christopher.a.martin@wcom.com
> Cc: 'Patrice Calhoun'; 'Michael Thomas'; 'Henning G. Schulzrinne';
> 'Anders Kristensen'; 'David Frascone'; sip@lists.bell-labs.com
> Subject: RE: [SIP] T2 and 182 Queued
>
>
>
> > > So, if I am to understand, authentication in SIP is mandatory
> > > and schemes that
> > > do not provide replay protection are not supported, correct?
>
> > I would disagree with this, and I know that you do to,
> replay prevention
> > needs to be implementd at some level, like at the provider
> level, not the
> > edge. Security should be a multilayered beast in the IP world.
>
> Sorry, the above doesn't parse :)
>
> I do not disagree with myself, I was actually being honest.
> If some level of
> authentication is required, then an additional replay
> protection method MUST
> be enforced. This could be done through timestamps, nonces (which are
> patented, btw), or other mechanisms. Either way, I don't see
> how providers
> guarantee replay protection (or even why I would trust some
> unknown entity to
> provide replay protection).
>
> PatC
>


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 13:32:44 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17208
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 13:32:43 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9240544390; Fri, 26 Jan 2001 12:22:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by lists.bell-labs.com (Postfix) with ESMTP id D2CF444336
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 12:21:56 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12983;
	Fri, 26 Jan 2001 10:21:20 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14996;
	Fri, 26 Jan 2001 10:21:19 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA01429;
	Fri, 26 Jan 2001 10:21:08 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: RE: [SIP] T2 and 182 Queued
To: christopher.a.martin@wcom.com
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        "'James Undery'" <jundery@ubiquity.net>,
        "'Michael Thomas'" <mat@cisco.com>,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" <001801c087c3$363e5100$6401010a@mcit.com>
Message-ID: <Roam.SIMC.2.0.6.980533267.7910.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 10:21:07 -0800 (PST)

> Actually tcp does not prevent spoofing the source IP address. There are
> hijack utilities in use today that perform this very task, and TCP is the
> vulnerability exploited in these attacks, some of them do this by guessing
> the TCP sequence numbers, others do it another way.
> 
> IPSec is the only real method to prevent spoofing and replay attacks.

S. Bellovin, "Defending Against Sequence Number Attacks", RFC 1948, May 1996.

I know that most serious operating system and router vendors do not ignore
such threats. Random sequence numbers are difficult to guess.

> > Once more I state (and did so in the e-mail you replied to)
> > that mandating
> > authentication is a workable solution. My question was
> > whether we could
> > mandate a non-replayable authentication scheme for all SIP messages.
> >
> I agree with this, we do need to mandate this type of scheme, but I believe
> that a non replayable mechanism would not be digest or hash authentication,
> rather PGP or possibly S/Mime may offer this level of protection.

Now I understand the confusion, we are talking about different problems. 

Yes, I agree that PK authentication would provide non-repudiation, and hence
be more difficult to forge than symmetric authentication schemes. However,
even assymetric based authentication protocols can be subjected to replay
attacks. Forging, or password theft is a different problem, but one that must
also be considered.

PatC


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 13:34:13 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17246
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 13:34:13 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 791D0443BC; Fri, 26 Jan 2001 12:25:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 70A66443B8
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 12:24:22 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14187;
	Fri, 26 Jan 2001 10:23:53 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15656;
	Fri, 26 Jan 2001 10:23:47 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA01490;
	Fri, 26 Jan 2001 10:23:45 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: RE: [SIP] T2 and 182 Queued
To: christopher.a.martin@wcom.com
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        "'Michael Thomas'" <mat@cisco.com>,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" <001901c087c4$5e439100$6401010a@mcit.com>
Message-ID: <Roam.SIMC.2.0.6.980533425.28335.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 10:23:45 -0800 (PST)

> Its all about trust.  :^)

of course :)

> 
> If along the way, during the TCP handshake someone were to decide to
> takeover, from the TCP ACK, by hijacking the session, how would this be
> prevented by the authentication methods supplied with SIP to date(not
> including PGP in this statement, which would be many levels better than
> digest and hash), TCP or not?

Agreed. If someone can redirect routes and intercept your packets, then you
are SOL.

PatC


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 13:41:14 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17572
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 13:41:14 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 48ADC44391; Fri, 26 Jan 2001 12:37:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 3767444391
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 12:36:25 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA02106;
	Fri, 26 Jan 2001 13:37:13 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9K2YQC>; Fri, 26 Jan 2001 13:30:55 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB1F1@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        James Undery <jundery@ubiquity.net>
Cc: Michael Thomas <mat@cisco.com>, christopher.a.martin@wcom.com,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        Anders Kristensen <Akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] T2 and 182 Queued
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 13:30:52 -0500


Wow... busy week prevents me from reading the sip list for 5 days and I come
back to a thread with 50 messages. 


 

> -----Original Message-----
> From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com]
> Sent: Friday, January 26, 2001 12:59 PM
> To: James Undery
> Cc: Patrice Calhoun; Michael Thomas; christopher.a.martin@wcom.com;
> 'Henning G. Schulzrinne'; 'Anders Kristensen'; 'David Frascone';
> sip@lists.bell-labs.com
> Subject: Re: [SIP] T2 and 182 Queued
> 
> TCP provides protection against the attacks Dave and I 
> mentioned, namely
> spoofed source IP address. Since TCP does require the 3 way 
> handshake, it
> would be VERY difficult for a hacker to mount a successful SIP attack.

Well, it would prevent just the attacks you mention. The general problem is
when an unauthenticated message causes either (1) state to be stored in some
system, or (2) more than one message to be automatically generated in
response to that. Even with TCP, there will be proxies that bomb just from
sending a stream of INVITEs over that established TCP connection, eventually
running out of memory or some other such thing.

> so, to restate my (and the position from IESG and their 
> security advisors)
> position, is that protocols MUST NOT introduce "new attacks".
> 
> Once more I state (and did so in the e-mail you replied to) 
> that mandating
> authentication is a workable solution. My question was 
> whether we could
> mandate a non-replayable authentication scheme for all SIP messages.

I don't think you can ever mandate anything, but there are certainly
recommendations that the specification can make. It would be helpful to look
at the various relationships in a SIP system; there are UAC to proxy, proxy
to proxy (both trusted peer and untrusted), proxy to UAS. I think you will
find that the solution you want differs in each case.

For UAC to proxy, Henning proposed the use of a stateless 407 challenge,
which works much like typical TCP SYN handshakes. Mike has complained that
the digest authentication provided  by SIP is not sufficiently strong. I
personally believe that there is no such thing as perfect security, and that
digest is far better than nothing. That aside, I'd welcome a draft on an
alternate, more secure user to proxy authentication mechanism that maintains
this stateless property. Until then, we can recommend that proxies not
establish state (i.e., they are always stateless proxies) for
unauthenticated messages.

For proxy to proxy, there are two cases. One is trusted, the case when a
company is, for example, purchasing wholesale termination services from
another (dialpad to Genuity, for example). In this case, something akin to
TLS is quite good. You establish the connection at the beginning of time,
and send all traffic over that. For untrusted, well, the recommendation
there is that your ingress proxies should generally be stateless until the
call is accepted. Assuming the acceptances aren't spoofed (and that needs to
be addressed as well), a 200 OK from a UAS is a good sign that the call is
not a DoS attack (there are issues with automated systems that answer
everything, I admit). The final interface is proxy to UAS. To avoid using
that as a DoS attack mechanism, the UAS should not create state or send
multiple messages unless it was able to either authenticate that the message
came from a trusted proxy (again, ala TLS, useful for proxy to gateway
connections), or from a trusted caller. 

I'm sure I've left some scenarios out, but its good that we are making
progress in identifying the issues.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 13:44:22 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17628
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 13:44:21 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0FF01443A9; Fri, 26 Jan 2001 12:39:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 9802744383
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 12:38:02 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA02163;
	Fri, 26 Jan 2001 13:40:44 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9K2YQR>; Fri, 26 Jan 2001 13:34:26 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB1F2@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Rick Dean'" <siplist@fdd.com>, sip@lists.bell-labs.com
Subject: This won't work, was: RE: [SIP] T2 and 182 Queued
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 13:34:24 -0500



 

> -----Original Message-----
> From: Rick Dean [mailto:siplist@fdd.com]
> Sent: Wednesday, January 24, 2001 2:45 PM
> To: sip@lists.bell-labs.com
> Subject: Re: [SIP] T2 and 182 Queued
> 
> 
> 
> An algorithm I am familiar with and is allowable
> by the standard, is the UAC retransmits
> an INVITE (same cSeq) ~30 seconds after a 
> provisional response is received to see if the 
> far end is still alive.  Because non-response to 
> a single INVITE is not conclusive,  the UAC
> restarts the 0.5, 1, 2, 4, 4,... sequence at
> this time.  If no response after N INVITES
> (where N <= 7 allowable in the spec) plus some
> time for the far end to do a sequence, the 
> call is considered dead.  This algorithm allows 
> the UAC to decide how frequently he wants to 
> check on the far end.  In the normal case
> each check costs two packets.

This doesn't work.

It doesn't work because stateful proxies between the caller and callee will
absorb these retransmissions. Your scheme will generate lots of traffic just
to verify that your high availability proxy is, in fact, still available,
and tell you absolutely zero about the availability of the far end UAS. 

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 13:51:25 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18004
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 13:51:24 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D853944357; Fri, 26 Jan 2001 12:48:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by lists.bell-labs.com (Postfix) with ESMTP id 046264434D
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 12:46:56 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA23350;
	Fri, 26 Jan 2001 10:46:25 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21250;
	Fri, 26 Jan 2001 10:46:18 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA02057;
	Fri, 26 Jan 2001 10:46:05 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: RE: [SIP] T2 and 182 Queued
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        James Undery <jundery@ubiquity.net>, Michael Thomas <mat@cisco.com>,
        christopher.a.martin@wcom.com,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        Anders Kristensen <Akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" <B65B4F8437968F488A01A940B21982BF9AB1F1@DYN-EXCH-001.dynamicsoft.com>
Message-ID: <Roam.SIMC.2.0.6.980534766.24840.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 10:46:06 -0800 (PST)

Welcome to the thread!

:)

> Well, it would prevent just the attacks you mention. The general problem is
> when an unauthenticated message causes either (1) state to be stored in some
> system, or (2) more than one message to be automatically generated in
> response to that. Even with TCP, there will be proxies that bomb just from
> sending a stream of INVITEs over that established TCP connection, eventually
> running out of memory or some other such thing.

I think that a reasonable proxy COULD in fact thottle back, or even drop
requests, when it detects that some attack is being mounted from a single TCP
connection.

> I don't think you can ever mandate anything, but there are certainly
> recommendations that the specification can make. It would be helpful to look
> at the various relationships in a SIP system; there are UAC to proxy, proxy
> to proxy (both trusted peer and untrusted), proxy to UAS. I think you will
> find that the solution you want differs in each case.

Sure.
> 
> For UAC to proxy, Henning proposed the use of a stateless 407 challenge,
> which works much like typical TCP SYN handshakes.
And I don't have a problem with this (and somehow missed his proposal in the
slew of e-mails). This is a workable solution. The original attack, which was
to fill up a queue, could issue a 407 at each new invite, and this would
eliminate the problem. In fact, even if authentication was disabled at this
point, there would STILL be some level of safety.

> Mike has complained that
> the digest authentication provided  by SIP is not sufficiently strong. I
> personally believe that there is no such thing as perfect security, and that
> digest is far better than nothing. That aside, I'd welcome a draft on an
> alternate, more secure user to proxy authentication mechanism that maintains
> this stateless property. Until then, we can recommend that proxies not
> establish state (i.e., they are always stateless proxies) for
> unauthenticated messages.

I believe that his point (if I can paraphrase from memory) is that replay is
required, and I do agree. Authentication w/o replay is not that useful, IMHO.

> 
> For proxy to proxy, there are two cases. One is trusted, the case when a
> company is, for example, purchasing wholesale termination services from
> another (dialpad to Genuity, for example). In this case, something akin to
> TLS is quite good. You establish the connection at the beginning of time,
> and send all traffic over that. For untrusted, well, the recommendation
> there is that your ingress proxies should generally be stateless until the
> call is accepted. Assuming the acceptances aren't spoofed (and that needs to
> be addressed as well), a 200 OK from a UAS is a good sign that the call is
> not a DoS attack (there are issues with automated systems that answer
> everything, I admit). The final interface is proxy to UAS. To avoid using
> that as a DoS attack mechanism, the UAS should not create state or send
> multiple messages unless it was able to either authenticate that the message
> came from a trusted proxy (again, ala TLS, useful for proxy to gateway
> connections), or from a trusted caller. 

I agree, but then stateless doesn't work well for 182 Queued, right?



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Fri Jan 26 14:02:32 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18328
	for <sip-archive@odin.ietf.org>; Fri, 26 Jan 2001 14:02:31 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1BE02443D3; Fri, 26 Jan 2001 12:59:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by lists.bell-labs.com (Postfix) with SMTP id 2362244382
	for <sip@lists.bell-labs.com>; Fri, 26 Jan 2001 12:58:08 -0500 (EST)
Received: (qmail 24995 invoked by uid 500); 26 Jan 2001 19:03:53 -0000
From: David Frascone <dave@frascone.com>
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        James Undery <jundery@ubiquity.net>, Michael Thomas <mat@cisco.com>,
        christopher.a.martin@wcom.com,
        "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        Anders Kristensen <Akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
Message-ID: <20010126130352.A24843@newman.frascone.com>
Mail-Followup-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
	Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
	James Undery <jundery@ubiquity.net>, Michael Thomas <mat@cisco.com>,
	christopher.a.martin@wcom.com,
	"'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
	Anders Kristensen <Akristensen@dynamicsoft.com>,
	'David Frascone' <dave@frascone.com>, sip@lists.bell-labs.com
References: <B65B4F8437968F488A01A940B21982BF9AB1F1@DYN-EXCH-001.dynamicsoft.com> <Roam.SIMC.2.0.6.980534766.24840.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Roam.SIMC.2.0.6.980534766.24840.pcalhoun@nasnfs>; from pcalhoun@nasnfs.eng.sun.com on Fri, Jan 26, 2001 at 10:46:06AM -0800
X-encrypt-payload: no
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Fri, 26 Jan 2001 13:03:53 -0600

On Fri, Jan 26, 2001 at 10:46:06AM -0800, Patrice Calhoun wrote:
> > 
> > For UAC to proxy, Henning proposed the use of a stateless 407 challenge,
> > which works much like typical TCP SYN handshakes.
> And I don't have a problem with this (and somehow missed his proposal in the
> slew of e-mails). This is a workable solution. The original attack, which was
> to fill up a queue, could issue a 407 at each new invite, and this would
> eliminate the problem. In fact, even if authentication was disabled at this
> point, there would STILL be some level of safety.

The only problem I have here is that one message (an INVITE) would generate
eleven or more (depending on T1) retransmissions of the 407.  So, one network
message will cause many more to be created.  But, it is definately better
than generating the retransmissions and generating network traffic to look up
the user.



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 04:06:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14551
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 04:06:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3435644337; Sat, 27 Jan 2001 03:07:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web1401.mail.yahoo.com (web1401.mail.yahoo.com [128.11.23.165])
	by lists.bell-labs.com (Postfix) with SMTP id B33CF44336
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 03:06:53 -0500 (EST)
Received: (qmail 18268 invoked by uid 60001); 27 Jan 2001 09:06:40 -0000
Message-ID: <20010127090640.18267.qmail@web1401.mail.yahoo.com>
Received: from [206.82.141.26] by web1401.mail.yahoo.com; Sat, 27 Jan 2001 01:06:40 PST
From: zeeshan razzaque <zrazzaque@yahoo.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] Codec Mismatch
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 01:06:40 -0800 (PST)

Hi,
I have doubts about the response the UAS should send
if the sdp in the invite has an unsupported codec.
Could someone plz tell me which call flows document
should I take a look at.
Thanx,
Zeeshan.

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices. 
http://auctions.yahoo.com/

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 04:39:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14677
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 04:39:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4E6074433B; Sat, 27 Jan 2001 03:40:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from dcn.ssu.ac.kr (dcn.ssu.ac.kr [203.253.2.104])
	by lists.bell-labs.com (Postfix) with ESMTP id B8FD044336
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 03:39:01 -0500 (EST)
Received: from softgear ([203.253.3.209])
	by dcn.ssu.ac.kr (8.10.1/8.10.1) with SMTP id f0R9W0X01494;
	Sat, 27 Jan 2001 18:32:00 +0900 (KST)
From: "???" <softgear@dcn.ssu.ac.kr>
To: <sip@lists.bell-labs.com>, "zeeshan razzaque" <zrazzaque@yahoo.com>
Subject: RE: [SIP] Codec Mismatch
Message-ID: <KIEFJGHGPFLKMLPOFDOLAEJICBAA.softgear@dcn.ssu.ac.kr>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <20010127090640.18267.qmail@web1401.mail.yahoo.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 18:37:59 +0900
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id EAA14677

I think that you should send 606 Not Acceptable
Thanks.
				softgear

-----Original Message-----
From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of zeeshan razzaque
Sent: Saturday, January 27, 2001 6:07 PM
To: sip@lists.bell-labs.com
Subject: [SIP] Codec Mismatch

Hi,
I have doubts about the response the UAS should send
if the sdp in the invite has an unsupported codec.
Could someone plz tell me which call flows document
should I take a look at.
Thanx,
Zeeshan.

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÓ†+%ŠËb±ú+r‰íŠ{¢ž^½éh¦g§¶‡í…äˆ>šè¶‡(—ôázÈ©þ)©•éžž×«þÉb²Ø¬¶©•§¶‡b±Ë¬²)©•éžžÖ­Š‰ÿjwm¢·œz+ÞiÛâqê'ºw^®ËZ�ا�ìb²Ø§‚È©ý:,¹»®&Þ¶ˆ­þǧvf¢–Ú&j:+v‰¨ýËÿr‰n™¸šýçnÂ+aþË›±Êâmë"§ø¦¦W¦z{h®ÏâžØ^n‡r


From sip-admin@lists.bell-labs.com  Sat Jan 27 05:06:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14758
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 05:06:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id AD6BA44341; Sat, 27 Jan 2001 04:07:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from romi-I.zapex.co.il (romi-I.zapex.co.il [199.203.146.3])
	by lists.bell-labs.com (Postfix) with ESMTP id 0975E44340
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 04:06:11 -0500 (EST)
Received: from lt070 ([10.10.10.15])
	by romi-I.zapex.co.il (8.9.3/8.9.3/romi-I $Revision: 1.4 $) with SMTP id MAA23184
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 12:03:10 +0200 (IST)
Reply-To: <orenl@zapex.co.il>
From: "Oren Louidor" <orenl@zapex.co.il>
To: <sip@lists.bell-labs.com>
Message-ID: <000801c08849$0865bfd0$0f0a0a0a@lt070>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Subject: [SIP] Call flows
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 12:08:00 +0200
Content-Transfer-Encoding: 7bit

Can anyone point me to documents with examples of call flows (with the SIP
messages themselves) of a video conference setup and control. I'm looking
for examples where the two sides support different codecs, with the
connection codecs established during the handshake. I'm also looking for
call flows for controlling the conference streams (like muting a media
channel, changing a codec, etc.).

Most of the documents I've found deal with establishing the connection, not
the connection content. Such documents would be appreciated as well.

TIA,
Oren.





_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 05:08:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14769
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 05:08:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5032D44340; Sat, 27 Jan 2001 04:09:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from romi-I.zapex.co.il (romi-I.zapex.co.il [199.203.146.3])
	by lists.bell-labs.com (Postfix) with ESMTP id CB2DD44336
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 04:08:06 -0500 (EST)
Received: from lt070 ([10.10.10.15])
	by romi-I.zapex.co.il (8.9.3/8.9.3/romi-I $Revision: 1.4 $) with SMTP id MAA23200
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 12:05:05 +0200 (IST)
Reply-To: <orenl@zapex.co.il>
From: "Oren Louidor" <orenl@zapex.co.il>
To: <sip@lists.bell-labs.com>
Message-ID: <000901c08849$4d44ab70$0f0a0a0a@lt070>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
Subject: [SIP] Bake-Off logs
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 12:09:56 +0200
Content-Transfer-Encoding: 7bit

Also,
Where can I get the logs of one of the bake-offs that took place ?

Oren.


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 06:27:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14965
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 06:27:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 26A674433F; Sat, 27 Jan 2001 05:28:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 7FCED44336
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 05:27:26 -0500 (EST)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id GAA16256;
	Sat, 27 Jan 2001 06:27:13 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id GAA05372;
	Sat, 27 Jan 2001 06:27:08 -0500 (EST)
Message-ID: <3A72AFA5.7318CB11@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Thomas <mat@cisco.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        christopher.a.martin@wcom.com,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
References: <Roam.SIMC.2.0.6.980455149.5856.pcalhoun@nasnfs>
		<3A7092A2.21DD6514@cs.columbia.edu> <14961.44530.289344.512637@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 03:23:17 -0800
Content-Transfer-Encoding: 7bit


>    I assume you're mainly talking about the UA-UA traffic
>    which assumes no previous communication, in which case
>    I agree. However UA->proxy, proxy-proxy, etc will
>    likely benefit from caching affects of keeping the SA's
>    up for some potentially indefinite time.

Unless you prohibit the sending of messages outside of such a security
context, this doesn't help with DOS attacks. In other words: unless you
can assume that every caller /upstream server (that you care about) has
IPsec, this doesn't help much. This may help with moving the problem
from the UA to the upstream proxy, but I doubt that for a protocol
designed to allow random communication, requiring IPsec is even a
midterm-feasible solution. For one, you probably need 256 MB of RAM to
implement IKE, so that this is not exactly a proposition for mobile
terminals :-)

>    Not really. Basic can easily be replayed, and digest
>    can as well, assuming that you're using the commonly
>    instantiated version which doesn't run a MAC over
>    the whole message with a new nonce for each message.
>    I assume that you'd consider per message challenges
>    unacceptible overhead.

>From what I can tell, intercept is mostly a theoretical threat, at least
for the DOS attacks that we're talking about here. Snooping remote
traffic is far from trivial unless you have compromised on of the
routers along the way. Also, the end system can implement simple
mechanisms that limit the ability for replay, very similar to the
windowing mechanism used in the IPsec anti-clogging mechanism.



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 06:28:51 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14976
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 06:28:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E509644352; Sat, 27 Jan 2001 05:28:21 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id A51F244336
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 05:27:31 -0500 (EST)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id GAA16260;
	Sat, 27 Jan 2001 06:27:18 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id GAA05376;
	Sat, 27 Jan 2001 06:27:14 -0500 (EST)
Message-ID: <3A72B143.A43FD05A@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: christopher.a.martin@wcom.com, "'Michael Thomas'" <mat@cisco.com>,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
References: <Roam.SIMC.2.0.6.980532362.9876.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 03:30:11 -0800
Content-Transfer-Encoding: 7bit

> patented, btw), or other mechanisms.

I believe that is an urban legend. Use of nonces may be patented in some
scenarios, but the basic concept of its use in various circumstances,
such as the one in Digest, has been known since the 1970s. If you're
trying the patent-scare tactic, please provide appropriate citations,
not just rumors.



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 06:29:43 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14987
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 06:29:43 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E613D44357; Sat, 27 Jan 2001 05:28:31 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id A311D44336
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 05:27:52 -0500 (EST)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id GAA16472;
	Sat, 27 Jan 2001 06:27:39 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id GAA05396;
	Sat, 27 Jan 2001 06:27:34 -0500 (EST)
Message-ID: <3A72D042.DDA6343B@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        James Undery <jundery@ubiquity.net>, Michael Thomas <mat@cisco.com>,
        christopher.a.martin@wcom.com,
        Anders Kristensen <Akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
References: <B65B4F8437968F488A01A940B21982BF9AB1F1@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 05:42:26 -0800
Content-Transfer-Encoding: 7bit


> For UAC to proxy, Henning proposed the use of a stateless 407 challenge,
> which works much like typical TCP SYN handshakes. Mike has complained that
> the digest authentication provided  by SIP is not sufficiently strong. I
> personally believe that there is no such thing as perfect security, and that

Before this acquires the state of perceived wisdom, the lack of strength
appears to be of the "if you don't implement the mechanisms available"
variety, i.e., it's not a protocol issue, it's mostly an implementation
issue. (It is true that the Digest checksums only cover parts of the
request. However, that has very little to do with the DOS issue.) The
general replay prevention for Digest authentication is exactly as strong
as IPsec replay prevention, with the qualification above. (I.e., it is
possible with Digest to snoop a message, change some parts of it, such
as the session description, and send it again within the time window
allowed by the replay window of the receiver. I'm not aware that similar
attacks have been perpetrated on HTTP, which has a similar problem in
most cases. Certainly has nothing to do with the common or likely DOS
attacks, where snooping is not part of the problem.)

> that as a DoS attack mechanism, the UAS should not create state or send
> multiple messages unless it was able to either authenticate that the message
> came from a trusted proxy (again, ala TLS, useful for proxy to gateway
> connections), or from a trusted caller.

That's essentially what I had proposed, unless I'm misreading your
comments.



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 06:30:39 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15002
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 06:30:39 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DFB5F4435E; Sat, 27 Jan 2001 05:28:43 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 9DA0444336
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 05:27:58 -0500 (EST)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id GAA16478;
	Sat, 27 Jan 2001 06:27:45 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id GAA05400;
	Sat, 27 Jan 2001 06:27:40 -0500 (EST)
Message-ID: <3A72D09C.7117D6DC@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        James Undery <jundery@ubiquity.net>, Michael Thomas <mat@cisco.com>,
        christopher.a.martin@wcom.com,
        Anders Kristensen <Akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
References: <Roam.SIMC.2.0.6.980534766.24840.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 05:43:56 -0800
Content-Transfer-Encoding: 7bit

> 
> I agree, but then stateless doesn't work well for 182 Queued, right?

Not an issue, according to the discussion. You wouldn't send 182 (or
anything but a single 40x) until the caller has been authenticated.



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 06:31:35 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15022
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 06:31:35 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C49F344366; Sat, 27 Jan 2001 05:29:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id E82E144336
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 05:28:14 -0500 (EST)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id GAA16507;
	Sat, 27 Jan 2001 06:28:01 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id GAA05416;
	Sat, 27 Jan 2001 06:27:57 -0500 (EST)
Message-ID: <3A72D2E0.4559C364@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Frascone <dave@frascone.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        James Undery <jundery@ubiquity.net>, Michael Thomas <mat@cisco.com>,
        christopher.a.martin@wcom.com,
        Anders Kristensen <Akristensen@dynamicsoft.com>,
        sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
References: <B65B4F8437968F488A01A940B21982BF9AB1F1@DYN-EXCH-001.dynamicsoft.com> <Roam.SIMC.2.0.6.980534766.24840.pcalhoun@nasnfs> <20010126130352.A24843@newman.frascone.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 05:53:36 -0800
Content-Transfer-Encoding: 7bit

> The only problem I have here is that one message (an INVITE) would generate
> eleven or more (depending on T1) retransmissions of the 407.  So, one network
> message will cause many more to be created.  But, it is definately better
> than generating the retransmissions and generating network traffic to look up
> the user.

Please reread my original email. It explicitly says to only send *one*
401/407 for unauthenticated requests, nothing else. This will need
clarification in the spec, but an implementation can do this today and
nobody will be able to prove that you did it...



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 07:15:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15216
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 07:15:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A0C0944356; Sat, 27 Jan 2001 06:16:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98])
	by lists.bell-labs.com (Postfix) with ESMTP id 562DC4434F
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 06:15:27 -0500 (EST)
Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21)
	id <CKD5QK7R>; Sat, 27 Jan 2001 04:14:58 -0800
Message-ID: <E79883AEA37FD411A58C00508BAC5F4B2B5CD4@exchange1.nuera.com>
From: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>
To: "'???'" <softgear@dcn.ssu.ac.kr>, sip@lists.bell-labs.com,
        zeeshan razzaque <zrazzaque@yahoo.com>
Subject: RE: [SIP] Codec Mismatch
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C0885A.C0E32640"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 04:14:53 -0800

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_01C0885A.C0E32640
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Zeeshan,=20

This is not the right list for the question - please post future =
questions
to the SIP Implementors list.... but I'll answer it as I disagree with
"???".

Assuming you mean that the INVITE _only_ contains unsupported the =
codes, the
correct response is normally 488 of 606 (as stated  Section B.2 of the
draft).=20

A 6xx response is normally only sent when a server knows definitively =
that
the _user_ is not able to accept the call _anywhere_ (eg, it knows that =
the
user associated with this Reuqets-URI instance is not logged into any =
other
server or available anywhere else). They are _not_ sent when the UA =
simply
knows the Request-URI is unavailable - only if the user associated with =
the
Request-URI is globally unavailable (which is a function of =
adminitrative
policy not SIP addresses). [See Section 7.6] A single 6xx response =
causes
all branches of a search to be cancelled.=20

For this reason, 4xx or 5xx responses are the normal response in most
situations (ie, 488 Not Acceptable Here). If everyone starts sending =
6xx
responses for everything then request forking at proxies is not goign =
to get
very far.

Robert.



> -----Original Message-----
> From: ??? [mailto:softgear@dcn.ssu.ac.kr]
> Sent: Saturday, January 27, 2001 8:38 PM
> To: sip@lists.bell-labs.com; zeeshan razzaque
> Subject: RE: [SIP] Codec Mismatch
>=20
>=20
> I think that you should send 606 Not Acceptable
> Thanks.
> 				softgear
>=20
> -----Original Message-----
> From: sip-admin@lists.bell-labs.com=20
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of zeeshan razzaque
> Sent: Saturday, January 27, 2001 6:07 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Codec Mismatch
>=20
> Hi,
> I have doubts about the response the UAS should send
> if the sdp in the invite has an unsupported codec.
> Could someone plz tell me which call flows document
> should I take a look at.
> Thanx,
> Zeeshan.
>=20
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - Buy the things you want at great prices.
> http://auctions.yahoo.com/
>=20
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> N=18=AC-+-S=C7=E8=AD=CA'=B6)=EESx=1Dz=F7=A5=A2(tm)zz=DA=1F=B6=17'=20
> =
=FAk=A2=DA=1C=A2T=E1z=C8=A9Sjezg=A7=B5=EA=EC-+-S=CBaz(tm)Zq=EBhv+=1C=BA=CB=
"s(tm)^(tm)=E9=EDj=D8=A8=9D=A9=DD=B6S=DEq=E8=AFy=A7o?=C7=A8
> z=E9=DDz=BB-jwbz=07=B1S=CBbz
> =
"=A5:,=B9=BB=1C=AE&=DE=B6^=AD=B1=E9=DD(tm)=A8=A5=B6?sZS=DD=A2j=1C=B1=CA%=
=BAf=E2i=E7n=C2+a=B2=E6=ECr=B8>z=C8=A9Sjezg=A7=B6S=ECS{ay=BA=1D
>=20

------_=_NextPart_001_01C0885A.C0E32640
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: [SIP] Codec Mismatch</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Zeeshan, </FONT>
</P>

<P><FONT SIZE=3D2>This is not the right list for the question - please =
post future questions to the SIP Implementors list.... but I'll answer =
it as I disagree with &quot;???&quot;.</FONT></P>

<P><FONT SIZE=3D2>Assuming you mean that the INVITE _only_ contains =
unsupported the codes, the correct response is normally 488 of 606 (as =
stated&nbsp; Section B.2 of the draft). </FONT></P>

<P><FONT SIZE=3D2>A 6xx response is normally only sent when a server =
knows definitively that the _user_ is not able to accept the call =
_anywhere_ (eg, it knows that the user associated with this Reuqets-URI =
instance is not logged into any other server or available anywhere =
else). They are _not_ sent when the UA simply knows the Request-URI is =
unavailable - only if the user associated with the Request-URI is =
globally unavailable (which is a function of adminitrative policy not =
SIP addresses). [See Section 7.6] A single 6xx response causes all =
branches of a search to be cancelled. </FONT></P>

<P><FONT SIZE=3D2>For this reason, 4xx or 5xx responses are the normal =
response in most situations (ie, 488 Not Acceptable Here). If everyone =
starts sending 6xx responses for everything then request forking at =
proxies is not goign to get very far.</FONT></P>

<P><FONT SIZE=3D2>Robert.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: ??? [<A =
HREF=3D"mailto:softgear@dcn.ssu.ac.kr">mailto:softgear@dcn.ssu.ac.kr</A>=
]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Saturday, January 27, 2001 8:38 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: sip@lists.bell-labs.com; zeeshan =
razzaque</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [SIP] Codec Mismatch</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think that you should send 606 Not =
Acceptable</FONT>
<BR><FONT SIZE=3D2>&gt; Thanks.</FONT>
<BR><FONT SIZE=3D2>&gt; &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; softgear</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: sip-admin@lists.bell-labs.com </FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:sip-admin@lists.bell-labs.com">mailto:sip-admin@lists.bel=
l-labs.com</A>]On Behalf Of zeeshan razzaque</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Saturday, January 27, 2001 6:07 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: sip@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [SIP] Codec Mismatch</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi,</FONT>
<BR><FONT SIZE=3D2>&gt; I have doubts about the response the UAS should =
send</FONT>
<BR><FONT SIZE=3D2>&gt; if the sdp in the invite has an unsupported =
codec.</FONT>
<BR><FONT SIZE=3D2>&gt; Could someone plz tell me which call flows =
document</FONT>
<BR><FONT SIZE=3D2>&gt; should I take a look at.</FONT>
<BR><FONT SIZE=3D2>&gt; Thanx,</FONT>
<BR><FONT SIZE=3D2>&gt; Zeeshan.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
__________________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Do You Yahoo!?</FONT>
<BR><FONT SIZE=3D2>&gt; Yahoo! Auctions - Buy the things you want at =
great prices.</FONT>
<BR><FONT SIZE=3D2>&gt; <A HREF=3D"http://auctions.yahoo.com/" =
TARGET=3D"_blank">http://auctions.yahoo.com/</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; This list is for continuing development of the =
SIP protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; The sip-implementer's list is the place to =
discuss implementation,</FONT>
<BR><FONT SIZE=3D2>&gt; and to receive advice on understanding existing =
sip.</FONT>
<BR><FONT SIZE=3D2>&gt; To subscribe to it, send mail to =
majordomo@cs.columbia.edu with</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;subscribe sip-implementors&quot; in the =
body.</FONT>
<BR><FONT SIZE=3D2>&gt; =
N=18=AC-+-&#352;=C7=E8=AD=CA'=B6)=EE&#352;x=1Dz=F7=A5=A2(tm)&#382;&#382;=
=DA=1F=B6=17' </FONT>
<BR><FONT SIZE=3D2>&gt; =
=FAk=A2=DA=1C=A2T=E1z=C8=A9&#352;jezg=A7=B5=EA=EC-+-&#352;=CBaz(tm)Zq=EB=
hv+=1C=BA=CB&quot;&#353;(tm)^(tm)=E9=EDj=D8=A8=9D=A9=DD=B6&#352;=DEq=E8=AF=
y=A7o&#8240;=C7=A8</FONT>
<BR><FONT SIZE=3D2>&gt; =
&#382;=E9=DDz=BB-jwb&#382;=07=B1&#352;=CBb&#382;</FONT>
<BR><FONT SIZE=3D2>&gt; =
&quot;=A5:,=B9=BB=1C=AE&amp;=DE=B6&#710;=AD=B1=E9=DD(tm)=A8=A5=B6&#8240;=
&#353;&#381;&#352;=DD=A2j=1C=B1=CA%=BAf=E2i=E7n=C2+a=B2=E6=ECr=B8&#8250;=
z=C8=A9&#352;jezg=A7=B6&#352;=EC&#352;{ay=BA=1D</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0885A.C0E32640--

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 12:18:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17002
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 12:18:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9CC4B44338; Sat, 27 Jan 2001 11:19:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web12403.mail.yahoo.com (web12403.mail.yahoo.com [216.136.173.130])
	by lists.bell-labs.com (Postfix) with SMTP id 9C33844336
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 11:18:37 -0500 (EST)
Message-ID: <20010127171824.45048.qmail@web12403.mail.yahoo.com>
Received: from [12.79.174.231] by web12403.mail.yahoo.com; Sun, 28 Jan 2001 01:18:24 CST
From: =?big5?q?h=20chang?= <lul8nl8n@yahoo.com.tw>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Subject: [SIP] A question on ACK
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 28 Jan 2001 01:18:24 +0800 (CST)
Content-Transfer-Encoding: 8bit


Is a UAC required to retransmit ACK like other
requests when using an unreliable transport? I cannot
find the answer in the current SIP spec. I would
apprecite any clarification from the list. Thanks.

H. Chang

_________________________________________________________
Do You Yahoo!?
µn°O§K¶Oªº @yahoo.com.tw ¹q¤l¶l¥ó @ http://mail.yahoo.com.tw
Get your free @yahoo.com.tw address at http://mail.yahoo.com.tw

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 13:05:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17203
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 13:05:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3DE9944346; Sat, 27 Jan 2001 12:06:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id E1C5F44336
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 12:05:08 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12725;
	Sat, 27 Jan 2001 10:04:53 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12695;
	Sat, 27 Jan 2001 10:04:52 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA21461;
	Sat, 27 Jan 2001 10:04:45 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: Re: [SIP] T2 and 182 Queued
To: Henning Schulzrinne <hgs@cs.columbia.edu>
Cc: sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" <3A72B143.A43FD05A@cs.columbia.edu>
Message-ID: <Roam.SIMC.2.0.6.980618686.29201.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 10:04:46 -0800 (PST)

> > patented, btw), or other mechanisms.
> 
> I believe that is an urban legend. Use of nonces may be patented in some
> scenarios, but the basic concept of its use in various circumstances,
> such as the one in Digest, has been known since the 1970s. If you're
> trying the patent-scare tactic, please provide appropriate citations,
> not just rumors.
> 

Sigh.

May I ask why you automatically assume I have ill-intentions, as opposed to
providing the WG with what I consider valuable information?

In any case, the patent I was referring to can be found in RFC 2002, and I
quote: "A.2. IBM Patent #5,148,479

   This patent, also assigned to IBM, may be relevant to those who
   implement nonce-based replay protection as described in Section
   5.6.2.  Note that nonce-based replay protection is an optional
   feature of this specification.  Timestamp-based replay protection, on
   the other hand, (Section 5.6.1) is a requirement of this
   specification."

PatC


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 13:52:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17435
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 13:52:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 47BA44433C; Sat, 27 Jan 2001 12:53:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 2A8D444336
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 12:52:24 -0500 (EST)
Received: from cisalpino.cs.columbia.edu (cisalpino.cs.columbia.edu [128.59.19.194])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA02701;
	Sat, 27 Jan 2001 13:52:10 -0500 (EST)
Received: from localhost (kns10@localhost)
	by cisalpino.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA12235;
	Sat, 27 Jan 2001 13:52:09 -0500 (EST)
From: Kundan Singh <kns10@cs.columbia.edu>
To: =?big5?q?h=20chang?= <lul8nl8n@yahoo.com.tw>
Cc: <sip@lists.bell-labs.com>
Subject: Re: [SIP] A question on ACK
In-Reply-To: <20010127171824.45048.qmail@web12403.mail.yahoo.com>
Message-ID: <Pine.SUN.4.30.0101271349190.12168-100000@cisalpino.cs.columbia.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 13:52:08 -0500 (EST)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id NAA17435



> Is a UAC required to retransmit ACK like other
> requests when using an unreliable transport? I cannot

No.
ACK is used to stop retransmission of final response to INVITE.
UAC should send ACK when it receives this final response.
If it receives the retransmitted final response (i.e.,
if previous ACK was lost, UAS will retransmit 200),
it sends the ACK again.

> find the answer in the current SIP spec. I would
> apprecite any clarification from the list. Thanks.
>
> H. Chang
>
> _________________________________________________________
> Do You Yahoo!?
> µn°O§K¶Oªº @yahoo.com.tw ¹q¤l¶l¥ó @ http://mail.yahoo.com.tw
> Get your free @yahoo.com.tw address at http://mail.yahoo.com.tw
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
>


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 17:21:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18438
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 17:21:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DDF3B4434F; Sat, 27 Jan 2001 16:22:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.40.143])
	by lists.bell-labs.com (Postfix) with ESMTP id 8EC5B44336
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 16:21:22 -0500 (EST)
Received: from cs.columbia.edu (adsl-151-198-20-48.nnj.adsl.bellatlantic.net [151.198.20.48])
	by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id RAA00404;
	Sat, 27 Jan 2001 17:21:12 -0500 (EST)
Message-ID: <3A7349A5.571E03AB@cs.columbia.edu>
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: Henning Schulzrinne <hgs@cs.columbia.edu>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
References: <Roam.SIMC.2.0.6.980618686.29201.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 17:20:21 -0500
Content-Transfer-Encoding: 7bit



Patrice Calhoun wrote:
> 
> > > patented, btw), or other mechanisms.
> >
> > I believe that is an urban legend. Use of nonces may be patented in some
> > scenarios, but the basic concept of its use in various circumstances,
> > such as the one in Digest, has been known since the 1970s. If you're
> > trying the patent-scare tactic, please provide appropriate citations,
> > not just rumors.
> >
> 
> Sigh.
> 
> May I ask why you automatically assume I have ill-intentions, as opposed to
> providing the WG with what I consider valuable information?

Sorry, didn't mean it to come across that way - unfortunately, I've
heard this type of argument ("I don't like X, and btw, it's patented") a
few too many times. You basically said "I don't like Digest, and btw,
you can't use its replay protection since it's patented."

> 
> In any case, the patent I was referring to can be found in RFC 2002, and I
> quote: "A.2. IBM Patent #5,148,479
> 
>    This patent, also assigned to IBM, may be relevant to those who
>    implement nonce-based replay protection as described in Section
>    5.6.2.  Note that nonce-based replay protection is an optional
>    feature of this specification.  Timestamp-based replay protection, on
>    the other hand, (Section 5.6.1) is a requirement of this
>    specification."

The same mechanism is used in IPsec and I've not heard anybody being
required to get a license from IBM. At least,
http://www.ietf.org/ipr.html does not mention it in that context, as far
as I can tell. More relevantly, RFC 2617 (Digest authentication) doesn't
make any such claims. RFC 2617 is not exactly a stealth RFC, so one
would imagine somebody raising it if this were an issue.

> 
> PatC

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 17:33:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18474
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 17:33:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2A1E244374; Sat, 27 Jan 2001 16:34:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id 84E9E44336
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 16:34:00 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29253;
	Sat, 27 Jan 2001 14:33:46 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25947;
	Sat, 27 Jan 2001 14:33:45 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA22777;
	Sat, 27 Jan 2001 14:33:40 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: Re: [SIP] T2 and 182 Queued
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        Henning Schulzrinne <hgs@cs.columbia.edu>, sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" <3A7349A5.571E03AB@cs.columbia.edu>
Message-ID: <Roam.SIMC.2.0.6.980634820.107.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 14:33:40 -0800 (PST)

> 
> Sorry, didn't mean it to come across that way - 
no problem.

> unfortunately, I've
> heard this type of argument ("I don't like X, and btw, it's patented") a
> few too many times. You basically said "I don't like Digest, and btw,
> you can't use its replay protection since it's patented."

hmmm... don't recall saying I don't like Digest. I have no problems with md5,
hmac-md5, hmac-sha1, or any other hashing algorithms used. I was simply
raising a point regarding someone's comment regarding Nonce's, which has been
a problem in Mobile IP.

> The same mechanism is used in IPsec and I've not heard anybody being
> required to get a license from IBM. At least,
> http://www.ietf.org/ipr.html does not mention it in that context, as far
> as I can tell. More relevantly, RFC 2617 (Digest authentication) doesn't
> make any such claims. RFC 2617 is not exactly a stealth RFC, so one
> would imagine somebody raising it if this were an issue.

I presume no one from IBM has been looking at IPSec that hard, and I won't
raise the issue there too. We can use Nonces all we like, that's not my point,
I was just providing my nonce experience that I came across in another WG.

PatC


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 17:42:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18553
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 17:42:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A561244380; Sat, 27 Jan 2001 16:43:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.40.143])
	by lists.bell-labs.com (Postfix) with ESMTP id 79AB34437C
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 16:42:36 -0500 (EST)
Received: from cs.columbia.edu (adsl-151-198-20-48.nnj.adsl.bellatlantic.net [151.198.20.48])
	by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id RAA10048;
	Sat, 27 Jan 2001 17:42:28 -0500 (EST)
Message-ID: <3A734EA0.F8645851@cs.columbia.edu>
From: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
References: <Roam.SIMC.2.0.6.980634820.107.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 17:41:36 -0500
Content-Transfer-Encoding: 7bit


> hmac-md5, hmac-sha1, or any other hashing algorithms used. I was simply
> raising a point regarding someone's comment regarding Nonce's, which has been
> a problem in Mobile IP.

However, nonce-based replay protection is a core part of RFC 2617
(Digest Authentication), which is what we're talking about here.

> 
> > The same mechanism is used in IPsec and I've not heard anybody being
> > required to get a license from IBM. At least,
> > http://www.ietf.org/ipr.html does not mention it in that context, as far
> > as I can tell. More relevantly, RFC 2617 (Digest authentication) doesn't
> > make any such claims. RFC 2617 is not exactly a stealth RFC, so one
> > would imagine somebody raising it if this were an issue.
> 
> I presume no one from IBM has been looking at IPSec that hard, and I won't
> raise the issue there too. We can use Nonces all we like, that's not my point,
> I was just providing my nonce experience that I came across in another WG.

The relevant RFC is RFC 2617, which describes Digest authentication, as
used in HTTP and SIP. 


> 
> PatC

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 17:51:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18618
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 17:51:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 81F6744385; Sat, 27 Jan 2001 16:52:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id E126B4436E
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 16:51:32 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02146;
	Sat, 27 Jan 2001 14:51:18 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06714;
	Sat, 27 Jan 2001 14:51:17 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA22872;
	Sat, 27 Jan 2001 14:51:12 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: Re: [SIP] T2 and 182 Queued
To: Henning Schulzrinne <schulzrinne@cs.columbia.edu>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>, sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" <3A734EA0.F8645851@cs.columbia.edu>
Message-ID: <Roam.SIMC.2.0.6.980635872.10921.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 14:51:12 -0800 (PST)

OK, and I see that HTTP uses Nonce as well. Regardless of the status of
Nonces, I believe we both agree that replay is required.

In any case, this isn't really germane to the original DoS topic. I feel like
I've provided the patent information I thought the WG needed to know, and we
can now move on.

Thanks,

PatC
> 
> > hmac-md5, hmac-sha1, or any other hashing algorithms used. I was simply
> > raising a point regarding someone's comment regarding Nonce's, which has been
> > a problem in Mobile IP.
> 
> However, nonce-based replay protection is a core part of RFC 2617
> (Digest Authentication), which is what we're talking about here.
> 
> > 
> > > The same mechanism is used in IPsec and I've not heard anybody being
> > > required to get a license from IBM. At least,
> > > http://www.ietf.org/ipr.html does not mention it in that context, as far
> > > as I can tell. More relevantly, RFC 2617 (Digest authentication) doesn't
> > > make any such claims. RFC 2617 is not exactly a stealth RFC, so one
> > > would imagine somebody raising it if this were an issue.
> > 
> > I presume no one from IBM has been looking at IPSec that hard, and I won't
> > raise the issue there too. We can use Nonces all we like, that's not my point,
> > I was just providing my nonce experience that I came across in another WG.
> 
> The relevant RFC is RFC 2617, which describes Digest authentication, as
> used in HTTP and SIP. 
> 
> 
> > 
> > PatC



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 19:57:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19129
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 19:57:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 33B5F44358; Sat, 27 Jan 2001 18:58:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by lists.bell-labs.com (Postfix) with ESMTP id 2DD8844336
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 18:57:58 -0500 (EST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA10126;
	Sat, 27 Jan 2001 16:57:45 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAT00451;
	Sat, 27 Jan 2001 16:57:30 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA28069; Sat, 27 Jan 2001 16:57:30 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14963.28282.137006.298467@thomasm-u1.cisco.com>
To: Henning Schulzrinne <hgs@cs.columbia.edu>
Cc: Jonathan Rosenberg <jdrosen@dynamicsoft.com>,
        "'Patrice Calhoun'" <pcalhoun@nasnfs.eng.sun.com>,
        James Undery <jundery@ubiquity.net>, Michael Thomas <mat@cisco.com>,
        christopher.a.martin@wcom.com,
        Anders Kristensen <Akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
In-Reply-To: <3A72D042.DDA6343B@cs.columbia.edu>
References: <B65B4F8437968F488A01A940B21982BF9AB1F1@DYN-EXCH-001.dynamicsoft.com>
	<3A72D042.DDA6343B@cs.columbia.edu>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 16:57:30 -0800 (PST)
Content-Transfer-Encoding: 7bit

Henning Schulzrinne writes:
 > 
 > > For UAC to proxy, Henning proposed the use of a stateless 407 challenge,
 > > which works much like typical TCP SYN handshakes. Mike has complained that
 > > the digest authentication provided  by SIP is not sufficiently strong. I
 > > personally believe that there is no such thing as perfect security, and that
 > 
 > Before this acquires the state of perceived wisdom, the lack of strength
 > appears to be of the "if you don't implement the mechanisms available"
 > variety, i.e., it's not a protocol issue, it's mostly an implementation
 > issue. (It is true that the Digest checksums only cover parts of the
 > request. However, that has very little to do with the DOS issue.) The
 > general replay prevention for Digest authentication is exactly as strong
 > as IPsec replay prevention, with the qualification above. 

   It's also a lot less efficient too, requiring a
   mandatory CMD->CHALLENGE->CMD+DIGEST loop each
   time. Digest doesn't work in the response
   direction either. What's to prevent an attacker
   from taking down a 911 center by an attacker
   spoofing 500 responses?

 > I.e., it is
 > possible with Digest to snoop a message, change some parts of it, such
 > as the session description, and send it again within the time window
 > allowed by the replay window of the receiver. I'm not aware that similar
 > attacks have been perpetrated on HTTP, which has a similar problem in
 > most cases. Certainly has nothing to do with the common or likely DOS
 > attacks, where snooping is not part of the problem.)

   If you're expecting to secure HTTP with digest
   and you're asking these kinds of questions,
   you've already outstriped the capabilities of 
   digest and should be using TLS.

		     Mike

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 20:15:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19186
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 20:15:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A42A244384; Sat, 27 Jan 2001 19:16:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 008C544381
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 19:15:52 -0500 (EST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA15207;
	Sat, 27 Jan 2001 17:15:20 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAT00464;
	Sat, 27 Jan 2001 17:15:06 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA28072; Sat, 27 Jan 2001 17:15:06 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14963.29338.544692.870760@thomasm-u1.cisco.com>
To: Henning Schulzrinne <hgs@cs.columbia.edu>
Cc: Michael Thomas <mat@cisco.com>,
        Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        christopher.a.martin@wcom.com,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
In-Reply-To: <3A72AFA5.7318CB11@cs.columbia.edu>
References: <Roam.SIMC.2.0.6.980455149.5856.pcalhoun@nasnfs>
	<3A7092A2.21DD6514@cs.columbia.edu>
	<14961.44530.289344.512637@thomasm-u1.cisco.com>
	<3A72AFA5.7318CB11@cs.columbia.edu>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 17:15:06 -0800 (PST)
Content-Transfer-Encoding: 7bit

Henning Schulzrinne writes:
 > 
 > >    I assume you're mainly talking about the UA-UA traffic
 > >    which assumes no previous communication, in which case
 > >    I agree. However UA->proxy, proxy-proxy, etc will
 > >    likely benefit from caching affects of keeping the SA's
 > >    up for some potentially indefinite time.
 > 
 > Unless you prohibit the sending of messages outside of such a security
 > context, this doesn't help with DOS attacks. In other words: unless you
 > can assume that every caller /upstream server (that you care about) has
 > IPsec, this doesn't help much.

   Er, uh, so? Cisco's VPN doesn't have provisions for
   IPsec-lacking remote security gateways. If you don't
   have IPsec, tough cookies. I don't see any reason
   why proxies and/or UA's would not take that obvious
   step if they were interested in stopping any number
   of attacks.

 > This may help with moving the problem
 > from the UA to the upstream proxy, but I doubt that for a protocol
 > designed to allow random communication, requiring IPsec is even a
 > midterm-feasible solution. For one, you probably need 256 MB of RAM to
 > implement IKE, so that this is not exactly a proposition for mobile
 > terminals :-)

   Oh, please. IPsec takes about the same amount of 
   code/data space as TLS, much of which is common
   functionality. If the terminals use that
   sort of cop out of why it's OK to transmit my
   stock transaction POST's in the clear, Ralph
   Nadar ought to consider a 21st century version
   of _Unsafe at Any Speed_.

 > >    Not really. Basic can easily be replayed, and digest
 > >    can as well, assuming that you're using the commonly
 > >    instantiated version which doesn't run a MAC over
 > >    the whole message with a new nonce for each message.
 > >    I assume that you'd consider per message challenges
 > >    unacceptible overhead.
 > 
 > >From what I can tell, intercept is mostly a theoretical threat, at least
 > for the DOS attacks that we're talking about here. Snooping remote
 > traffic is far from trivial unless you have compromised on of the
 > routers along the way. 

   It's not just DoS attacks, obviously. And given 
   the rise of shared and unsecured media (802.11,
   hello?) I think that anybody who thinks that
   this is "theoretical" deserves what they get.

 > Also, the end system can implement simple
 > mechanisms that limit the ability for replay, very similar to the
 > windowing mechanism used in the IPsec anti-clogging mechanism.

   Huh? With Digest? Do tell.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 20:27:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19221
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 20:27:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 874844437C; Sat, 27 Jan 2001 19:28:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 13B384436E
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 19:27:11 -0500 (EST)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA21037;
	Sat, 27 Jan 2001 20:26:57 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id UAA08624;
	Sat, 27 Jan 2001 20:26:56 -0500 (EST)
Message-ID: <3A73A088.1C6DA076@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Thomas <mat@cisco.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        christopher.a.martin@wcom.com,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
References: <Roam.SIMC.2.0.6.980455149.5856.pcalhoun@nasnfs>
		<3A7092A2.21DD6514@cs.columbia.edu>
		<14961.44530.289344.512637@thomasm-u1.cisco.com>
		<3A72AFA5.7318CB11@cs.columbia.edu> <14963.29338.544692.870760@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 20:31:04 -0800
Content-Transfer-Encoding: 7bit

>    Er, uh, so? Cisco's VPN doesn't have provisions for
>    IPsec-lacking remote security gateways. If you don't
>    have IPsec, tough cookies. I don't see any reason
>    why proxies and/or UA's would not take that obvious
>    step if they were interested in stopping any number
>    of attacks.

By definition, VPNs are pre-configured. Phone calls aren't.

>    Oh, please. IPsec takes about the same amount of
>    code/data space as TLS, much of which is common
>    functionality. If the terminals use that
>    sort of cop out of why it's OK to transmit my
>    stock transaction POST's in the clear, Ralph
>    Nadar ought to consider a 21st century version
>    of _Unsafe at Any Speed_.

I doubt that devices will support TLS, either, at least not all of them.
After all, most web transactions are not on TLS, either. (And most
embedded web servers don't support TLS.)

>    It's not just DoS attacks, obviously. And given
>    the rise of shared and unsecured media (802.11,
>    hello?) I think that anybody who thinks that
>    this is "theoretical" deserves what they get.

Yes, the listener on the local 802.11 can spoof your requests. We're
talking about DOS attacks, which tend to be longer range. 

> 
>  > Also, the end system can implement simple
>  > mechanisms that limit the ability for replay, very similar to the
>  > windowing mechanism used in the IPsec anti-clogging mechanism.
> 
>    Huh? With Digest? Do tell.

See the discussion in RFC 2617 for details and trade-offs.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 20:46:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19285
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 20:46:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9900044391; Sat, 27 Jan 2001 19:47:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 99F0044336
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 19:46:17 -0500 (EST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA21664;
	Sat, 27 Jan 2001 17:45:44 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAT00488;
	Sat, 27 Jan 2001 17:45:32 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA28078; Sat, 27 Jan 2001 17:45:32 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14963.31164.232162.833103@thomasm-u1.cisco.com>
To: Henning Schulzrinne <hgs@cs.columbia.edu>
Cc: Michael Thomas <mat@cisco.com>,
        Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        christopher.a.martin@wcom.com,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
In-Reply-To: <3A73A088.1C6DA076@cs.columbia.edu>
References: <Roam.SIMC.2.0.6.980455149.5856.pcalhoun@nasnfs>
	<3A7092A2.21DD6514@cs.columbia.edu>
	<14961.44530.289344.512637@thomasm-u1.cisco.com>
	<3A72AFA5.7318CB11@cs.columbia.edu>
	<14963.29338.544692.870760@thomasm-u1.cisco.com>
	<3A73A088.1C6DA076@cs.columbia.edu>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 17:45:32 -0800 (PST)
Content-Transfer-Encoding: 7bit

Henning Schulzrinne writes:
 > >    Er, uh, so? Cisco's VPN doesn't have provisions for
 > >    IPsec-lacking remote security gateways. If you don't
 > >    have IPsec, tough cookies. I don't see any reason
 > >    why proxies and/or UA's would not take that obvious
 > >    step if they were interested in stopping any number
 > >    of attacks.
 > 
 > By definition, VPNs are pre-configured. Phone calls aren't.

   You're splitting hairs. If a proxy and/or UA wants
   to subject itself to the infinite variety of attacks
   that can happen when you don't use crypto, fine;
   there's no protocol police to arrest you for doing
   stupid things.

   Tell me Henning: are you suggesting that from an IETF
   standpoint we should be endorsing non-crypto based
   fake "security"?

 > >    Oh, please. IPsec takes about the same amount of
 > >    code/data space as TLS, much of which is common
 > >    functionality. If the terminals use that
 > >    sort of cop out of why it's OK to transmit my
 > >    stock transaction POST's in the clear, Ralph
 > >    Nadar ought to consider a 21st century version
 > >    of _Unsafe at Any Speed_.
 > 
 > I doubt that devices will support TLS, either, at least not all of them.
 > After all, most web transactions are not on TLS, either. (And most
 > embedded web servers don't support TLS.)

   Sure. They sold cars with exploding fuel tanks too.
   Are you suggesting that we should endorse bad designs?

 > >    It's not just DoS attacks, obviously. And given
 > >    the rise of shared and unsecured media (802.11,
 > >    hello?) I think that anybody who thinks that
 > >    this is "theoretical" deserves what they get.
 > 
 > Yes, the listener on the local 802.11 can spoof your requests. We're
 > talking about DOS attacks, which tend to be longer range. 

   By this arguement, Basic is completely adequate too.

   As I've said, DoS attacks are but one piece of security.
   I don't understand why you insist on trying to frame
   the discussion as if the only consideration with 
   security were DoS attacks. If that were the only 
   consideration, you might have a point. It isn't.

		      Mike

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 21:29:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19384
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 21:29:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4B03A4436E; Sat, 27 Jan 2001 20:30:07 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id C816844336
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 20:29:53 -0500 (EST)
Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA23623;
	Sat, 27 Jan 2001 21:29:40 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA08830;
	Sat, 27 Jan 2001 21:29:38 -0500 (EST)
Message-ID: <3A73AF3A.D3A983BB@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Thomas <mat@cisco.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        christopher.a.martin@wcom.com,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
References: <Roam.SIMC.2.0.6.980455149.5856.pcalhoun@nasnfs>
		<3A7092A2.21DD6514@cs.columbia.edu>
		<14961.44530.289344.512637@thomasm-u1.cisco.com>
		<3A72AFA5.7318CB11@cs.columbia.edu>
		<14963.29338.544692.870760@thomasm-u1.cisco.com>
		<3A73A088.1C6DA076@cs.columbia.edu> <14963.31164.232162.833103@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 21:33:46 -0800
Content-Transfer-Encoding: 7bit

I'm not disagreeing with providing as much security as possible.
However, given the 20k lines implementation complexity of IPsec and IKE,
it is simply at this point unrealistic to say "let's simply put MUST
implement IPsec in the draft and be done with it". That's why a range of
security solutions, some better than others, is useful, depending on the
threat model and the cost trade-offs. I'd have rather have people
implement Digest than nothing (and rather implement IPsec and/or TLS on
top of that). We've made progress in that almost all SIP implementations
nowadays implement Digest authentication. Given the sorry state of
public key infrastructures right now and the uncertainties which model
will prevail (all the KINK and PKCROSS stuff is pretty much wishful
thinking right now, after all), it is rather premature to require IPsec
or TLS, say.

Unlike VPN boxes and PCs, IP phones are consumer devices that need to
sell at not much more than $100. In a few years, that $100 may include
enough memory to run Linux or another real OS. Right now and for the
next few years, it's an embedded OS with a few hundred KB of memory at
the low end. Having built such devices, I can tell you from experience
that this makes TCP iffy and IPsec with IKE/TLS an impossibility, given
what else you have to support to have an operational device.

For proxy servers, TLS with web-like certs may be deployable right now,
although probably again as a means for server verification, not client.
(I.e., Digest or Basic on top of SSL, as is typical for web servers.)

It is instructive to see how much progress secure email has made over
the years, even though the issues there are somewhat simpler (e.g.,
latency is not an issue) and software has been available for a  number
of years now. I wish it were different, but it's clear that the forcing
mechanism hasn't been there to get people to regularly use crypto on
that. SIP is rather similar to email in many ways, including random,
non-pre-configured configuration and a range of devices.

We've talked about authentication in general ad nauseam on this list,
with the same arguments again and again between the "realists" and the
"maximalists". We continue to disagree about the availability and
timeframe of a client-level keying infrastructure and no amount of email
is going to resolve this, given that the current reality is clearly that
we have at best some approximation of domain-level authentication (in
TLS certs for web servers) and preconfigured secrets. We can speculate
how fast this reality is likely to change, but I doubt we'll make much
progress.

That's why I wanted to focus on DOS attacks, which seems at least a
somewhat new topic.

Comparing things to exploding fuel tanks is not particularly helpful
here.


Michael Thomas wrote:
> 
> Henning Schulzrinne writes:
>  > >    Er, uh, so? Cisco's VPN doesn't have provisions for
>  > >    IPsec-lacking remote security gateways. If you don't
>  > >    have IPsec, tough cookies. I don't see any reason
>  > >    why proxies and/or UA's would not take that obvious
>  > >    step if they were interested in stopping any number
>  > >    of attacks.
>  >
>  > By definition, VPNs are pre-configured. Phone calls aren't.
> 
>    You're splitting hairs. If a proxy and/or UA wants
>    to subject itself to the infinite variety of attacks
>    that can happen when you don't use crypto, fine;
>    there's no protocol police to arrest you for doing
>    stupid things.
> 
>    Tell me Henning: are you suggesting that from an IETF
>    standpoint we should be endorsing non-crypto based
>    fake "security"?

I'd like to give people a range of choices, rather than making
unrealistic prescriptions, with the outcome that the default choice
(nothing) gets implemented.

> 
>  > >    Oh, please. IPsec takes about the same amount of
>  > >    code/data space as TLS, much of which is common
>  > >    functionality. If the terminals use that
>  > >    sort of cop out of why it's OK to transmit my
>  > >    stock transaction POST's in the clear, Ralph
>  > >    Nadar ought to consider a 21st century version
>  > >    of _Unsafe at Any Speed_.
>  >
>  > I doubt that devices will support TLS, either, at least not all of them.
>  > After all, most web transactions are not on TLS, either. (And most
>  > embedded web servers don't support TLS.)
> 
>    Sure. They sold cars with exploding fuel tanks too.
>    Are you suggesting that we should endorse bad designs?

We should endorse designs that can be as secure as other services that
are similarly situated and can be operated and manufactured at
resasonable cost. After all, the safety of a Volvo compared to a Geo
Metro has reasons and costs...

>    By this arguement, Basic is completely adequate too.

Well, for DOS Basic is probably a good first defense. For almost all
attackers, it will be very difficult to create a valid password, so it
would get rid of all but the most sophicated DOS attacks. Again, as
stated, given that we've ground general authentication into list dust a
few times, I'm concentrating on the topic at hand.


> 
>    As I've said, DoS attacks are but one piece of security.
>    I don't understand why you insist on trying to frame
>    the discussion as if the only consideration with
>    security were DoS attacks. If that were the only
>    consideration, you might have a point. It isn't.

See above. We can solve, to a degree similar to current TCP services,
the DOS part without having to wish upon a new world order of security
infrastructures. That's progress.

> 
>                       Mike

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sat Jan 27 22:25:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20473
	for <sip-archive@odin.ietf.org>; Sat, 27 Jan 2001 22:25:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A771C4437E; Sat, 27 Jan 2001 21:26:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by lists.bell-labs.com (Postfix) with ESMTP id C74BC44336
	for <sip@lists.bell-labs.com>; Sat, 27 Jan 2001 21:25:42 -0500 (EST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id TAA20378;
	Sat, 27 Jan 2001 19:25:00 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAT00533;
	Sat, 27 Jan 2001 19:24:58 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id TAA28083; Sat, 27 Jan 2001 19:24:57 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14963.37129.775893.628640@thomasm-u1.cisco.com>
To: Henning Schulzrinne <hgs@cs.columbia.edu>
Cc: Michael Thomas <mat@cisco.com>,
        Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        christopher.a.martin@wcom.com,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
In-Reply-To: <3A73AF3A.D3A983BB@cs.columbia.edu>
References: <Roam.SIMC.2.0.6.980455149.5856.pcalhoun@nasnfs>
	<3A7092A2.21DD6514@cs.columbia.edu>
	<14961.44530.289344.512637@thomasm-u1.cisco.com>
	<3A72AFA5.7318CB11@cs.columbia.edu>
	<14963.29338.544692.870760@thomasm-u1.cisco.com>
	<3A73A088.1C6DA076@cs.columbia.edu>
	<14963.31164.232162.833103@thomasm-u1.cisco.com>
	<3A73AF3A.D3A983BB@cs.columbia.edu>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sat, 27 Jan 2001 19:24:57 -0800 (PST)
Content-Transfer-Encoding: 7bit

Henning Schulzrinne writes:
 > I'm not disagreeing with providing as much security as possible.
 > However, given the 20k lines implementation complexity of IPsec and IKE,
 > it is simply at this point unrealistic to say "let's simply put MUST
 > implement IPsec in the draft and be done with it". That's why a range of
 > security solutions, some better than others, is useful, depending on the
 > threat model and the cost trade-offs. I'd have rather have people
 > implement Digest than nothing (and rather implement IPsec and/or TLS on
 > top of that). We've made progress in that almost all SIP implementations
 > nowadays implement Digest authentication. Given the sorry state of
 > public key infrastructures right now and the uncertainties which model
 > will prevail (all the KINK and PKCROSS stuff is pretty much wishful
 > thinking right now, after all), it is rather premature to require IPsec
 > or TLS, say.

Henning,

The cost of implementing strong crypto on a
consumer class box is probably less than $1. Maybe
less than $.50. Moore's law will make the cost of
crypto an utterly insignificant cost in the
future. Also: MEGACO and MGCP mandate the use of
IPsec, and the main feedback there was the worry
that third party IP stacks might not be able to
get IPsec and as a result they put in an
intermediate solution of requiring application
layer AH headers. I believe that the current
consensus is that that was probably not necessary.

Digest is worse than nothing at all (Basic at
least doesn't cop an attitude that it's anything
less than inadequate): as currently -- and likely
forever -- implemented does not provide basic
security features like replay protection,
bidirectional authentication or confidentiality.
For the SIP WG to suggest that it is the least
common denominator will do far more harm than
good: it will merely postpone the day that
effective strong crypto is used until _after_ the
phone phreaks phind phun.

 > It is instructive to see how much progress secure email has made over
 > the years [...]

No it's not. Mail has twenty years of baggage
to contend with. Neither SIP or MEGAGO/MGCP have
to deal with that particular intractablity.

 > We've talked about authentication in general ad nauseam on this list,
 > with the same arguments again and again between the "realists" and the
 > "maximalists". We continue to disagree about the availability and
 > timeframe of a client-level keying infrastructure and no amount of email
 > is going to resolve this, given that the current reality is clearly that
 > we have at best some approximation of domain-level authentication (in
 > TLS certs for web servers) and preconfigured secrets. We can speculate
 > how fast this reality is likely to change, but I doubt we'll make much
 > progress.
 > 
 > That's why I wanted to focus on DOS attacks, which seems at least a
 > somewhat new topic.

And the answer is the same and you don't like the
answer again. Quelle surprise.

What I don't buy is that the SIP WG should spend
one iota of time on dealing with DoS attacks on
unsecured transactions. It comes with the
territory and the sooner we can point to the
obvious advice, "use strong crypto", the sooner we
can get back to the things that people in this WG
are capable of solving. Every other half step is
a complete waste of time.

		     Mike

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sun Jan 28 04:48:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07419
	for <sip-archive@odin.ietf.org>; Sun, 28 Jan 2001 04:48:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 449CE4438B; Sun, 28 Jan 2001 03:49:08 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from contela.com (unknown [211.169.249.227])
	by lists.bell-labs.com (Postfix) with ESMTP id CE2A344336
	for <sip@lists.bell-labs.com>; Sun, 28 Jan 2001 03:48:47 -0500 (EST)
Received: from hkjung ([203.236.3.225])
	(authenticated)
	by contela.com (8.10.2/8.10.2) with ESMTP id f0S9cCI17192;
	Sun, 28 Jan 2001 18:38:12 +0900
Message-ID: <004a01c0890f$8b28de40$21171796@sktelecom.com>
Reply-To: "???" <hkjung@contela.com>
From: "???" <hkjung@contela.com>
To: "Rick Dean" <siplist@fdd.com>, "Rohan Mahy" <rohan@cisco.com>
Cc: <sip@lists.bell-labs.com>
References: <5.0.0.25.2.20010117162639.01b82090@imop.cisco.com>
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0047_01C0895A.F7987680"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 28 Jan 2001 18:48:56 +0900

This is a multi-part message in MIME format.

------=_NextPart_000_0047_01C0895A.F7987680
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

RGVhciBhbGwuIA0KDQpJIGFtIHNvbWUgY3VyaW91cyBhYm91dCBIQU5ET0ZGIG1ldGhvZC4gDQpJ
IHRoaW5rLCBIQU5ET0ZGIG1ldGhvZCBpcyByZXF1aXJlZCB3aGVuIFNJUCB0ZXJtaW5hbCBtb3Zl
cyBmcm9tIG9uZSBuZXR3b3JrIHRvIG90aGVyIG5ldHdvcmsuIA0KDQpJbiAzR1BQIFRSMjMuODIx
LCB0aGUgc2VudGVuc2UsDQoiIEFzIGEgY29uc2VxdWVuY2UsIHRoZSBiZWhhdmlvdXIgb2YgdGhl
IG11bHRpbWVkaWEgY2FsbCBjb250cm9sIHNlcnZlciAoQ1NDRikgY2FuIGJlIHRoZSBzYW1lIHdo
YXRldmVyIHRoZSBhY2Nlc3MgdGVjaG5vbG9neSAocmFkaW8gb3Igd2lyZWQtbGluZSkuIE11bHRp
bWVkaWEgY2FsbCBjb250cm9sL21vYmlsaXR5IG1hbmFnZW1lbnQgc2hhbGwgbm90IGJlIGF3YXJl
IG9mIHRoZSBhY2Nlc3MgdGVjaG5vbG9neTogdGhlIG11bHRpbWVkaWEgQ2FsbCBDb250cm9sIChD
U0NGKSBkb2VzIG5vdCBoYW5kbGUgbm90aW9ucyBzdWNoIGFzIEhhbmQtT3ZlciwgUkEsICINCg0K
SXQgbWVhbnMgdGhhdCBoYW5kb2ZmIGlzIHRoZSBwcm9ibGVtIG9mIEdHU04gYW5kIFNHU04gbm90
IENTQ0Ygd2hpY2ggc3VwcG9ydCBTSVAgcHJvdG9jb2wuIEl0IGlzIG5vdCB0aGUgYnVzaW5lc3Mg
b2YgQ1NDRi4gDQoNClRoZXJlZm9yZSBJIHRoaW5rIEhBTkRPRkYgbWV0aG9kIGlzIG5vdCByZXF1
aXJlZCBhdCBsZWFzdCAzR1BQLiANCg0KV2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgdGhpcz8gDQoN
Cg0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBSb2hhbiBNYWh5IA0K
ICBUbzogUmljayBEZWFuIA0KICBDYzogc2lwQGxpc3RzLmJlbGwtbGFicy5jb20gDQogIFNlbnQ6
IFRodXJzZGF5LCBKYW51YXJ5IDE4LCAyMDAxIDEwOjMzIEFNDQogIFN1YmplY3Q6IFJlOiBbU0lQ
XSBkcmFmdC1pZXRmLXNpcC1oYW5kb2ZmLTAwcHJlOC50eHQNCg0KDQogIFJpY2ssDQoNCiAgVGhh
bmtzIGZvciBwcmVwYXJpbmcgdGhpcyBzbyBxdWlja2x5LiAgQSBmZXcgcXVlc3Rpb25zIGFyZSBi
ZWxvdy4NCg0KICAtSW4gc2VjdGlvbiA1DQoNCiAgICAgICBUaGUgSEFORE9GRiByZXF1ZXN0IG1h
eSBjb250YWluIGEgYm9keSBvZiBNSU1FLXR5cGUNCiAgICAgICBhcHBsaWNhdGlvbi9zaXAtaGVh
ZGVycywgd2hpY2ggY29udGFpbnMgaGVhZGVycyByZXF1ZXN0ZWQgdG8gYmUNCiAgICAgICBjb3Bp
ZWQgaW50byB0aGUgc3Bhd25lZCBJTlZJVEUgcmVxdWVzdC4gIEZvciBhIEhBTkRPRkYgcmVxdWVz
dCwgdGhlDQogICAgICAgIlJlZmVyLVRvIiBVUkkgU0hPVUxEIE5PVCBpbmNsdWRlIHF1ZXN0aW9u
LW1hcmsgZGVsaW1pdGVkIGhlYWRlcnMgZm9yDQogICAgICAgdGhlIHN1YnNlcXVlbnQgSU5WSVRF
LiAgDQoNCiAgV2hhdCBkbyB5b3UgZG8gaWYgeW91IGdldCBoZWFkZXJzIGluIHRoZSBSZWZlci1U
byAoaWdub3JlLCBpc3N1ZSBlcnJvciB4KT8gIA0KDQoNCiAgICBUaGVzZSBoZWFkZXJzIFNIT1VM
RCBiZSBjb3BpZWQgdG8gdGhlDQogICAgICAgcmVzdWx0aW5nIElOVklURSB3aXRob3V0IGVzY2Fw
aW5nIHByb2Nlc3NpbmcuICANCg0KICBCeSAiVGhlc2UgaGVhZGVycyIgZG8geW91IG1lYW4gdGhl
IGhlYWRlcnMgaW4gdGhlIGJvZHkgb3IgdGhlIGhlYWRlcnMgdGhhdCB5b3UgU0hPVUxEIE5PVCBw
dXQgaW50byB0aGUgUmVmZXItVG8gVVJJPyAgDQoNCg0KICAgIFRoaXMgTUlNRSB0eXBlIE1VU1QN
CiAgICAgICBOT1QgY29udGFpbiBhIGhlYWRlciB3aGljaCBiZWdpbnMgd2l0aCB0d28gZGFzaGVz
LCAiLS0iLiAgVGhpcyBNSU1FDQogICAgICAgdHlwZSBNVVNUIE5PVCBpbmNsdWRlIGEgY2FsbC1p
ZCBoZWFkZXIsIGJ1dCBpbnN0ZWFkIHVzZSBhICJyZXBsYWNlcyINCiAgICAgICBoZWFkZXIgZm9y
IHRoaXMgZnVuY3Rpb25hbGl0eS4gIFRoaXMgTUlNRSB0eXBlIE1VU1QgTk9UIGluY2x1ZGUgYQ0K
ICAgICAgICJoYW5kb2ZmIiBoZWFkZXIuDQoNCiAgV2hhdCBlcnJvciBzaG91bGQgeW91IHJldHVy
biBpZiB5b3UgZGV0ZWN0IHRoaXMgc3R1ZmY/DQoNCiAgLVRoZSBmYWN0IHRoYXQgeW91IGNhbiBo
YXZlIGEgImhlYWRlciBib2R5IiBhbmQgYSBzZXNzaW9uIGRlc2NyaXB0aW9uIGltcGxpZXMgbXVs
dGlwYXJ0LiAgRG8geW91IHJlYWxseSB3YW50IHRvIGRvIHRoYXQ/DQoNCiAgLVRoZSB3YXkgeW91
IHNob3cgdGhlIGZsb3dzLCB0aGUgdHJhbnNmZXJvciBzZW5kcyB0aGUgaGFuZG9mZiwgYW5kIHRo
ZW4gaG9sZHMgaXRzIGNhbGwocykgdXAuICBXaGF0IGhhcHBlbnMgaWYgdGhlIHRyYW5zZmVyZWUg
Y3Jhc2hlcyBhZnRlciBPS2luZyB0aGUgSEFORE9GRj8gIFlvdSB3b3VsZCBoYXZlIHRvIGtlZXAg
dGhlIGNhbGwgdXAgImZvcmV2ZXIiIHJpZ2h0PyAgUHJlc3VtYWJseSBpZiB0aGUgdHJhbnNmZXJv
ciB3YW50cyB0byBiZSByaWQgb2YgdGhlIGNhbGwsIGl0IGNvdWxkIHNlbmQgYSBCWUU/DQoNCiAg
VGFrZSB0aGUgZm9sbG93aW5nIGV4YW1wbGUgd2hlcmUgSSBiZWdpbiBhbiBhdHRlbmRlZCB0cmFu
c2ZlciwgYnV0IEkgZ2V0IHRpcmVkIG9mIHdhaXRpbmcuICANCg0KICBBICAgICAgICAgICAgICAg
QiAgICAgICAgICAgICAgIEMNCiAgSU5WSVRFIC0+DQogIDwtIDE4MA0KICA8LSAyMDANCiAgQUNL
IC0+DQoNCiAgSU5WSVRFIC0tLS0tLS0tLS0tLS0+DQogIDwtLS0tLS0tLS0xODAtLS0tLS0tLQ0K
DQogIChzZXZlcmFsIHJpbmdzIGxhdGVyKQ0KICBIQU5ET0ZGIC0+DQogIDwtIDIwMA0KICAgICAg
ICAgICAgICAgICAgSU5WSVRFIC0tLS0tPg0KICAgICAgICAgICAgICAgICAgcmVwbGFjZXM6DQog
ICAgICAgICAgICAgICAgICA8LS0tIDE4MCAtLS0tDQogIDwtIE5PVElGWQ0KICBoYW5kb2ZmLXN0
YXR1czogMTgwDQogIDIwMCAtPg0KICBCWUUgLT4NCiAgPC0gMjAwDQogICAgICAgICAgICAgICAg
ICANCiAgLUhBTkRPRkYgc2Vla3MgdG8gZmlsbCBhIG11Y2ggc21hbGxlciByb2xlIGluIHRoZSBj
YWxsIGNvbnRyb2wgZnJhbWV3b3JrIHRoYW4gc29tZSBvZiB1cyBhZHZvY2F0ZSBmb3IgUkVGRVIu
IEl0IHNlZW1zIHlvdSBhcmUgYWR2b2NhdGluZyBhIGZyYW1ld29yayB3aXRoIGEgbGFyZ2VyIG51
bWJlciBvZiBtb3JlIHNwZWNpZmljL3NtYWxsZXIgcHJpbWl0aXZlcy4gIFBIT05FQ1RMIHdvdWxk
IGJlIG9uZSBvZiB0aGVzZSBwcmltaXRpdmVzLiAgV2hhdCBwcmltaXRpdmUgKHdoYXQgd291bGQg
aXQgbG9vayBsaWtlIGluIHlvdXIgdmVyc2lvbiBvZiBodGUgZnJhbWV3b3JrKSBkbyB5b3UgYWR2
b2NhdGUgdG8gcmVwbGFjZS91bnJlcGxhY2UgeW91cnNlbGYgW2FzIGluIHRoZSBNdXNpYyBvbiBI
b2xkIGV4YW1wbGUgSSBnYXZlXT8gIEhvdyBhYm91dCBhIHByaW1pdGl2ZSBmb3IgYWQtaG9jIGNv
bmZlcmVuY2luZz8NCg0KICB0aGFua3MsDQogIC1yb2hhbg0KDQogIEF0IDEwOjI2IEFNIDEvMTcv
MDEsIFJpY2sgRGVhbiB3cm90ZToNCg0KDQogICAgRGVhciBTSVAgbGlzdCwNCg0KICAgIEFsdGhv
dWdoIHdlIHdvdWxkIGxpa2UgbW9yZSB0aW1lIHRvIA0KICAgIGVkaXQgdGhpcyBwb29yIGRyYWZ0
LCB3ZSBmZWVsIGEgc25lYWsNCiAgICBwZWVrIGlzIHdhcnJhbnRlZCBkdWUgdG8gaXRzIHVyZ2Vu
dCBuYXR1cmUNCiAgICB3aXRoIHRoZSB1cGNvbW1pbmcgbWVldGluZy4NCg0KICAgIGh0dHA6Ly9w
aG9uZWN0bC5zZm91ci5jb20vZHJhZnQtaWV0Zi1zaXAtaGFuZG9mZi0wMHByZTgudHh0DQoNCiAg
ICBTb21lIHNpZ25pZmljYW50IGRpZmZlcmVuY2VzIGZyb20gUkVGRVIgYXJlOg0KICAgICAgKiBu
YXJyb3dlciBzY29wZQ0KICAgICAgKiBtZXRob2QgY29tcGxldGVzIHdpdGhvdXQgcHJvbXB0aW5n
DQogICAgICAqIHJlZmVycmVkLWJ5IGxpa2UgaGVhZGVyIGdlbmVyYXRlZCBieSB0cmFuc2ZlcmVl
DQogICAgICAqIGxvY2F0aW9uIG9mIGhlYWRlcnMgZm9yIHNwYXduZWQgaW52aXRlDQogICAgICAq
IGVycm9yIHByb2Nlc3NpbmcgJiBmaW5hbCBub3RpZmljYXRpb24NCg0KICAgIENoZWVycywNCiAg
ICBSaWNrDQogICAgcmlja19kZWFuQDNjb20uY29tDQoNCg0KICAgIF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgVGhpcyBsaXN0IGlzIGZvciBjb250
aW51aW5nIGRldmVsb3BtZW50IG9mIHRoZSBTSVAgcHJvdG9jb2wuDQogICAgVGhlIHNpcC1pbXBs
ZW1lbnRlcidzIGxpc3QgaXMgdGhlIHBsYWNlIHRvIGRpc2N1c3MgaW1wbGVtZW50YXRpb24sDQog
ICAgYW5kIHRvIHJlY2VpdmUgYWR2aWNlIG9uIHVuZGVyc3RhbmRpbmcgZXhpc3Rpbmcgc2lwLg0K
ICAgIFRvIHN1YnNjcmliZSB0byBpdCwgc2VuZCBtYWlsIHRvIG1ham9yZG9tb0Bjcy5jb2x1bWJp
YS5lZHUgd2l0aA0KICAgICJzdWJzY3JpYmUgc2lwLWltcGxlbWVudG9ycyIgaW4gdGhlIGJvZHku
DQoNCg0K

------=_NextPart_000_0047_01C0895A.F7987680
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M
IDUuNTAuNDEzNC42MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+
DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7
JiM0NzU0ODsgc2l6ZT0yPkRlYXIgYWxsLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9
JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBm
YWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPkkgYW0gc29tZSBjdXJpb3VzIGFib3V0IEhBTkRP
RkYgbWV0aG9kLiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4
OyBzaXplPTI+SSB0aGluaywgSEFORE9GRiBtZXRob2QgaXMgcmVxdWlyZWQgd2hlbiBTSVAgdGVy
bWluYWwgDQptb3ZlcyBmcm9tIG9uZSBuZXR3b3JrIHRvIG90aGVyIG5ldHdvcmsuIDwvRk9OVD48
L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj48L0ZPTlQ+Jm5i
c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+SW4gM0dQ
UCBUUjIzLjgyMSwgdGhlIHNlbnRlbnNlLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y
PjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4Oz4iIEFzIGEgY29uc2VxdWVuY2UsIHRoZSBiZWhh
dmlvdXIgb2YgdGhlIA0KbXVsdGltZWRpYSBjYWxsIGNvbnRyb2wgc2VydmVyIChDU0NGKSBjYW4g
YmUgdGhlIHNhbWUgd2hhdGV2ZXIgdGhlIGFjY2VzcyANCnRlY2hub2xvZ3kgKHJhZGlvIG9yIHdp
cmVkLWxpbmUpLiA8Rk9OVCBjb2xvcj0jZmYwMDAwPk11bHRpbWVkaWEgY2FsbCANCmNvbnRyb2wv
bW9iaWxpdHkgbWFuYWdlbWVudCBzaGFsbCBub3QgYmUgYXdhcmUgb2YgdGhlIGFjY2VzcyB0ZWNo
bm9sb2d5OjwvRk9OVD4gDQo8Rk9OVCBjb2xvcj0jZmYwMDAwPnRoZSBtdWx0aW1lZGlhIENhbGwg
Q29udHJvbCAoQ1NDRikgZG9lcyBub3QgaGFuZGxlIG5vdGlvbnMgDQpzdWNoIGFzIEhhbmQtT3Zl
ciwgUkEsICI8L0ZPTlQ+PC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0
NDA0OyYjNDc1NDg7IGNvbG9yPSNmZjAwMDAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE
SVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IGNvbG9yPSNmZjAwMDAgc2l6ZT0yPjxGT05U
IGNvbG9yPSMwMDAwMDA+SXQgbWVhbnMgdGhhdCANCmhhbmRvZmYgaXMgdGhlIHByb2JsZW0gb2Yg
R0dTTiBhbmQgU0dTTiBub3QgQ1NDRiB3aGljaCBzdXBwb3J0IFNJUCANCnByb3RvY29sLiZuYnNw
O0l0IGlzIG5vdCB0aGUgYnVzaW5lc3Mgb2YgQ1NDRi4gPC9GT05UPjwvRk9OVD48L0RJVj4NCjxE
SVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+
DQo8RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+VGhlcmVmb3JlIEkgdGhp
bmsgSEFORE9GRiBtZXRob2QgaXMgbm90IHJlcXVpcmVkIGF0IA0KbGVhc3QgM0dQUC4gPC9GT05U
PjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPjwvRk9OVD4m
bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzQ0NDA0OyYjNDc1NDg7IHNpemU9Mj5XaGF0
IGRvIHlvdSB0aGluayBhYm91dCB0aGlzPyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9
JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBm
YWNlPSYjNDQ0MDQ7JiM0NzU0ODsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj48L0RJVj4NCjxC
TE9DS1FVT1RFIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7
IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lO
LVJJR0hUOiAwcHgiPg0KICA8RElWIHN0eWxlPSJGT05UOiAxMHB0ICYjNDQ0MDQ7JiM0NzU0ODsi
Pi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgDQogIHN0eWxlPSJC
QUNLR1JPVU5EOiAjZTRlNGU0OyBGT05UOiAxMHB0ICYjNDQ0MDQ7JiM0NzU0ODs7IGZvbnQtY29s
b3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gPEEgDQogIHRpdGxlPXJvaGFuQGNpc2NvLmNvbSBocmVm
PSJtYWlsdG86cm9oYW5AY2lzY28uY29tIj5Sb2hhbiBNYWh5PC9BPiA8L0RJVj4NCiAgPERJViBz
dHlsZT0iRk9OVDogMTBwdCAmIzQ0NDA0OyYjNDc1NDg7Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPXNp
cGxpc3RAZmRkLmNvbSANCiAgaHJlZj0ibWFpbHRvOnNpcGxpc3RAZmRkLmNvbSI+UmljayBEZWFu
PC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCAmIzQ0NDA0OyYjNDc1NDg7Ij48
Qj5DYzo8L0I+IDxBIHRpdGxlPXNpcEBsaXN0cy5iZWxsLWxhYnMuY29tIA0KICBocmVmPSJtYWls
dG86c2lwQGxpc3RzLmJlbGwtbGFicy5jb20iPnNpcEBsaXN0cy5iZWxsLWxhYnMuY29tPC9BPiA8
L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCAmIzQ0NDA0OyYjNDc1NDg7Ij48Qj5TZW50
OjwvQj4gVGh1cnNkYXksIEphbnVhcnkgMTgsIDIwMDEgMTA6MzMgDQogIEFNPC9ESVY+DQogIDxE
SVYgc3R5bGU9IkZPTlQ6IDEwcHQgJiM0NDQwNDsmIzQ3NTQ4OyI+PEI+U3ViamVjdDo8L0I+IFJl
OiBbU0lQXSANCiAgZHJhZnQtaWV0Zi1zaXAtaGFuZG9mZi0wMHByZTgudHh0PC9ESVY+DQogIDxE
SVY+PEJSPjwvRElWPlJpY2ssPEJSPjxCUj5UaGFua3MgZm9yIHByZXBhcmluZyB0aGlzIHNvIHF1
aWNrbHkuJm5ic3A7IEEgZmV3IA0KICBxdWVzdGlvbnMgYXJlIGJlbG93LjxCUj48QlI+LUluIHNl
Y3Rpb24gNTxCUj4NCiAgPEJMT0NLUVVPVEUgY2xhc3M9Y2l0ZSBjaXRlIHR5cGU9ImNpdGUiPiZu
YnNwOyZuYnNwOyBUaGUgSEFORE9GRiByZXF1ZXN0IG1heSANCiAgICBjb250YWluIGEgYm9keSBv
ZiBNSU1FLXR5cGU8QlI+Jm5ic3A7Jm5ic3A7IGFwcGxpY2F0aW9uL3NpcC1oZWFkZXJzLCB3aGlj
aCANCiAgICBjb250YWlucyBoZWFkZXJzIHJlcXVlc3RlZCB0byBiZTxCUj4mbmJzcDsmbmJzcDsg
Y29waWVkIGludG8gdGhlIHNwYXduZWQgDQogICAgSU5WSVRFIHJlcXVlc3QuJm5ic3A7IEZvciBh
IEhBTkRPRkYgcmVxdWVzdCwgdGhlPEJSPiZuYnNwOyZuYnNwOyAiUmVmZXItVG8iIA0KICAgIFVS
SSBTSE9VTEQgTk9UIGluY2x1ZGUgcXVlc3Rpb24tbWFyayBkZWxpbWl0ZWQgaGVhZGVycyBmb3I8
QlI+Jm5ic3A7Jm5ic3A7IA0KICAgIHRoZSBzdWJzZXF1ZW50IElOVklURS4mbmJzcDsgPC9CTE9D
S1FVT1RFPjxCUj5XaGF0IGRvIHlvdSBkbyBpZiB5b3UgZ2V0IA0KICBoZWFkZXJzIGluIHRoZSBS
ZWZlci1UbyAoaWdub3JlLCBpc3N1ZSBlcnJvciB4KT8mbmJzcDsgPEJSPjxCUj4NCiAgPEJMT0NL
UVVPVEUgY2xhc3M9Y2l0ZSBjaXRlIHR5cGU9ImNpdGUiPlRoZXNlIGhlYWRlcnMgU0hPVUxEIGJl
IGNvcGllZCB0byANCiAgICB0aGU8QlI+Jm5ic3A7Jm5ic3A7IHJlc3VsdGluZyBJTlZJVEUgd2l0
aG91dCBlc2NhcGluZyBwcm9jZXNzaW5nLiZuYnNwOyANCiAgPC9CTE9DS1FVT1RFPjxCUj5CeSAi
VGhlc2UgaGVhZGVycyIgZG8geW91IG1lYW4gdGhlIGhlYWRlcnMgaW4gdGhlIGJvZHkgb3IgdGhl
IA0KICBoZWFkZXJzIHRoYXQgeW91IFNIT1VMRCBOT1QgcHV0IGludG8gdGhlIFJlZmVyLVRvIFVS
ST8mbmJzcDsgPEJSPjxCUj4NCiAgPEJMT0NLUVVPVEUgY2xhc3M9Y2l0ZSBjaXRlIHR5cGU9ImNp
dGUiPlRoaXMgTUlNRSB0eXBlIE1VU1Q8QlI+Jm5ic3A7Jm5ic3A7IA0KICAgIE5PVCBjb250YWlu
IGEgaGVhZGVyIHdoaWNoIGJlZ2lucyB3aXRoIHR3byBkYXNoZXMsICItLSIuJm5ic3A7IFRoaXMg
DQogICAgTUlNRTxCUj4mbmJzcDsmbmJzcDsgdHlwZSBNVVNUIE5PVCBpbmNsdWRlIGEgY2FsbC1p
ZCBoZWFkZXIsIGJ1dCBpbnN0ZWFkIHVzZSANCiAgICBhICJyZXBsYWNlcyI8QlI+Jm5ic3A7Jm5i
c3A7IGhlYWRlciBmb3IgdGhpcyBmdW5jdGlvbmFsaXR5LiZuYnNwOyBUaGlzIE1JTUUgDQogICAg
dHlwZSBNVVNUIE5PVCBpbmNsdWRlIGE8QlI+Jm5ic3A7Jm5ic3A7ICJoYW5kb2ZmIiBoZWFkZXIu
PC9CTE9DS1FVT1RFPjxCUj5XaGF0IA0KICBlcnJvciBzaG91bGQgeW91IHJldHVybiBpZiB5b3Ug
ZGV0ZWN0IHRoaXMgc3R1ZmY/PEJSPjxCUj4tVGhlIGZhY3QgdGhhdCB5b3UgDQogIGNhbiBoYXZl
IGEgImhlYWRlciBib2R5IiBhbmQgYSBzZXNzaW9uIGRlc2NyaXB0aW9uIGltcGxpZXMgbXVsdGlw
YXJ0LiZuYnNwOyBEbyANCiAgeW91IHJlYWxseSB3YW50IHRvIGRvIHRoYXQ/PEJSPjxCUj4tVGhl
IHdheSB5b3Ugc2hvdyB0aGUgZmxvd3MsIHRoZSB0cmFuc2Zlcm9yIA0KICBzZW5kcyB0aGUgaGFu
ZG9mZiwgYW5kIHRoZW4gaG9sZHMgaXRzIGNhbGwocykgdXAuJm5ic3A7IFdoYXQgaGFwcGVucyBp
ZiB0aGUgDQogIHRyYW5zZmVyZWUgY3Jhc2hlcyBhZnRlciBPS2luZyB0aGUgSEFORE9GRj8mbmJz
cDsgWW91IHdvdWxkIGhhdmUgdG8ga2VlcCB0aGUgDQogIGNhbGwgdXAgImZvcmV2ZXIiIHJpZ2h0
PyZuYnNwOyBQcmVzdW1hYmx5IGlmIHRoZSB0cmFuc2Zlcm9yIHdhbnRzIHRvIGJlIHJpZCBvZiAN
CiAgdGhlIGNhbGwsIGl0IGNvdWxkIHNlbmQgYSBCWUU/PEJSPjxCUj5UYWtlIHRoZSBmb2xsb3dp
bmcgZXhhbXBsZSB3aGVyZSBJIGJlZ2luIA0KICBhbiBhdHRlbmRlZCB0cmFuc2ZlciwgYnV0IEkg
Z2V0IHRpcmVkIG9mIHdhaXRpbmcuJm5ic3A7IDxCUj48QlI+PEZPTlQgDQogIGZhY2U9IkNvdXJp
ZXIsIENvdXJpZXIiPkE8WC1UQUI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7PC9YLVRBQj48WC1UQUI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7PC9YLVRBQj5CPFgtVEFCPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOzwvWC1UQUI+PFgtVEFCPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOzwvWC1UQUI+QzxCUj5JTlZJVEUgDQogIC0mZ3Q7PEJSPiZsdDst
IDE4MDxCUj4mbHQ7LSAyMDA8QlI+QUNLIC0mZ3Q7PEJSPjxCUj5JTlZJVEUgDQogIC0tLS0tLS0t
LS0tLS0mZ3Q7PEJSPiZsdDstLS0tLS0tLS0xODAtLS0tLS0tLTxCUj48QlI+KHNldmVyYWwgcmlu
Z3MgDQogIGxhdGVyKTxCUj5IQU5ET0ZGIC0mZ3Q7PEJSPiZsdDstIA0KICAyMDA8QlI+PFgtVEFC
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvWC1UQUI+
PFgtVEFCPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwv
WC1UQUI+SU5WSVRFIA0KICAtLS0tLSZndDs8QlI+PFgtVEFCPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvWC1UQUI+PFgtVEFCPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvWC1UQUI+cmVwbGFjZXM6PEJSPjxY
LVRBQj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L1gt
VEFCPjxYLVRBQj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDs8L1gtVEFCPiZsdDstLS0gDQogIDE4MCAtLS0tPEJSPiZsdDstIE5PVElGWTxCUj5oYW5kb2Zm
LXN0YXR1czogMTgwPEJSPjIwMCAtJmd0OzxCUj5CWUUgDQogIC0mZ3Q7PEJSPiZsdDstIA0KICAy
MDA8QlI+PC9GT05UPjxYLVRBQj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDs8L1gtVEFCPjxYLVRBQj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDs8L1gtVEFCPjxCUj4tSEFORE9GRiANCiAgc2Vla3MgdG8gZmlsbCBh
IG11Y2ggc21hbGxlciByb2xlIGluIHRoZSBjYWxsIGNvbnRyb2wgZnJhbWV3b3JrIHRoYW4gc29t
ZSBvZiANCiAgdXMgYWR2b2NhdGUgZm9yIFJFRkVSLiBJdCBzZWVtcyB5b3UgYXJlIGFkdm9jYXRp
bmcgYSBmcmFtZXdvcmsgd2l0aCBhIGxhcmdlciANCiAgbnVtYmVyIG9mIG1vcmUgc3BlY2lmaWMv
c21hbGxlciBwcmltaXRpdmVzLiZuYnNwOyBQSE9ORUNUTCB3b3VsZCBiZSBvbmUgb2YgDQogIHRo
ZXNlIHByaW1pdGl2ZXMuJm5ic3A7IFdoYXQgcHJpbWl0aXZlICh3aGF0IHdvdWxkIGl0IGxvb2sg
bGlrZSBpbiB5b3VyIA0KICB2ZXJzaW9uIG9mIGh0ZSBmcmFtZXdvcmspIGRvIHlvdSBhZHZvY2F0
ZSB0byByZXBsYWNlL3VucmVwbGFjZSB5b3Vyc2VsZiBbYXMgaW4gDQogIHRoZSBNdXNpYyBvbiBI
b2xkIGV4YW1wbGUgSSBnYXZlXT8mbmJzcDsgSG93IGFib3V0IGEgcHJpbWl0aXZlIGZvciBhZC1o
b2MgDQogIGNvbmZlcmVuY2luZz88QlI+PEJSPnRoYW5rcyw8QlI+LXJvaGFuPEJSPjxCUj5BdCAx
MDoyNiBBTSAxLzE3LzAxLCBSaWNrIERlYW4gDQogIHdyb3RlOjxCUj48QlI+DQogIDxCTE9DS1FV
T1RFIGNsYXNzPWNpdGUgY2l0ZSB0eXBlPSJjaXRlIj5EZWFyIFNJUCBsaXN0LDxCUj48QlI+QWx0
aG91Z2ggd2UgDQogICAgd291bGQgbGlrZSBtb3JlIHRpbWUgdG8gPEJSPmVkaXQgdGhpcyBwb29y
IGRyYWZ0LCB3ZSBmZWVsIGEgc25lYWs8QlI+cGVlayBpcyANCiAgICB3YXJyYW50ZWQgZHVlIHRv
IGl0cyB1cmdlbnQgbmF0dXJlPEJSPndpdGggdGhlIHVwY29tbWluZyBtZWV0aW5nLjxCUj48QlI+
PEEgDQogICAgaHJlZj0iaHR0cDovL3Bob25lY3RsLnNmb3VyLmNvbS9kcmFmdC1pZXRmLXNpcC1o
YW5kb2ZmLTAwcHJlOC50eHQiIA0KICAgIGV1ZG9yYT0iYXV0b3VybCI+aHR0cDovL3Bob25lY3Rs
LnNmb3VyLmNvbS9kcmFmdC1pZXRmLXNpcC1oYW5kb2ZmLTAwcHJlOC50eHQ8L0E+PEJSPjxCUj5T
b21lIA0KICAgIHNpZ25pZmljYW50IGRpZmZlcmVuY2VzIGZyb20gUkVGRVIgYXJlOjxCUj4mbmJz
cDsgKiBuYXJyb3dlciBzY29wZTxCUj4mbmJzcDsgDQogICAgKiBtZXRob2QgY29tcGxldGVzIHdp
dGhvdXQgcHJvbXB0aW5nPEJSPiZuYnNwOyAqIHJlZmVycmVkLWJ5IGxpa2UgaGVhZGVyIA0KICAg
IGdlbmVyYXRlZCBieSB0cmFuc2ZlcmVlPEJSPiZuYnNwOyAqIGxvY2F0aW9uIG9mIGhlYWRlcnMg
Zm9yIHNwYXduZWQgDQogICAgaW52aXRlPEJSPiZuYnNwOyAqIGVycm9yIHByb2Nlc3NpbmcgJmFt
cDsgZmluYWwgDQogICAgbm90aWZpY2F0aW9uPEJSPjxCUj5DaGVlcnMsPEJSPlJpY2s8QlI+cmlj
a19kZWFuQDNjb20uY29tPEJSPjxCUj48QlI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188QlI+VGhpcyANCiAgICBsaXN0IGlzIGZvciBjb250aW51aW5nIGRl
dmVsb3BtZW50IG9mIHRoZSBTSVAgcHJvdG9jb2wuPEJSPlRoZSANCiAgICBzaXAtaW1wbGVtZW50
ZXIncyBsaXN0IGlzIHRoZSBwbGFjZSB0byBkaXNjdXNzIGltcGxlbWVudGF0aW9uLDxCUj5hbmQg
dG8gDQogICAgcmVjZWl2ZSBhZHZpY2Ugb24gdW5kZXJzdGFuZGluZyBleGlzdGluZyBzaXAuPEJS
PlRvIHN1YnNjcmliZSB0byBpdCwgc2VuZCANCiAgICBtYWlsIHRvIG1ham9yZG9tb0Bjcy5jb2x1
bWJpYS5lZHUgd2l0aDxCUj4ic3Vic2NyaWJlIHNpcC1pbXBsZW1lbnRvcnMiIGluIA0KICAgIHRo
ZSBib2R5LjwvQkxPQ0tRVU9URT48QlI+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hUTUw+DQo=

------=_NextPart_000_0047_01C0895A.F7987680--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sun Jan 28 10:11:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08833
	for <sip-archive@odin.ietf.org>; Sun, 28 Jan 2001 10:11:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E8B0244390; Sun, 28 Jan 2001 09:12:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id B943D44336
	for <sip@lists.bell-labs.com>; Sun, 28 Jan 2001 09:11:37 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA24968;
	Sun, 28 Jan 2001 10:11:01 -0500 (EST)
Message-ID: <3A743684.70213936@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Thomas <mat@cisco.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        christopher.a.martin@wcom.com,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
References: <Roam.SIMC.2.0.6.980455149.5856.pcalhoun@nasnfs>
		<3A7092A2.21DD6514@cs.columbia.edu>
		<14961.44530.289344.512637@thomasm-u1.cisco.com>
		<3A72AFA5.7318CB11@cs.columbia.edu>
		<14963.29338.544692.870760@thomasm-u1.cisco.com>
		<3A73A088.1C6DA076@cs.columbia.edu>
		<14963.31164.232162.833103@thomasm-u1.cisco.com>
		<3A73AF3A.D3A983BB@cs.columbia.edu> <14963.37129.775893.628640@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 28 Jan 2001 10:11:01 -0500
Content-Transfer-Encoding: 7bit

Michael Thomas wrote:
> 

> 
> The cost of implementing strong crypto on a
> consumer class box is probably less than $1. Maybe

This is bogus. Have you tried to actually built one of those boxes? I
have and I know the prices for SRAM and DRAM, which are still major
components of the end system cost.


> less than $.50. Moore's law will make the cost of
> crypto an utterly insignificant cost in the
> future. Also: MEGACO and MGCP mandate the use of
> IPsec, and the main feedback there was the worry

Megaco and MGCP are also almost exclusively run without IPsec right now
(Apparently, they aren't used all that much, but that's a separate
problem). Plus, they are fixed-association devices across a single
network hop, so none of the difficulties we're discussing here apply.

> that third party IP stacks might not be able to
> get IPsec and as a result they put in an
> intermediate solution of requiring application
> layer AH headers. I believe that the current
> consensus is that that was probably not necessary.
> 
> Digest is worse than nothing at all (Basic at
> least doesn't cop an attitude that it's anything
> less than inadequate): as currently -- and likely
> forever -- implemented does not provide basic
> security features like replay protection,

You keep repeating this, but that still doesn't make it correct.

> bidirectional authentication or confidentiality.
> For the SIP WG to suggest that it is the least
> common denominator will do far more harm than
> good: it will merely postpone the day that
> effective strong crypto is used until _after_ the
> phone phreaks phind phun.
> 
>  > It is instructive to see how much progress secure email has made over
>  > the years [...]
> 
> No it's not. Mail has twenty years of baggage
> to contend with. Neither SIP or MEGAGO/MGCP have
> to deal with that particular intractablity.

This is not a baggage issue. All modern email clients, probably
representing 90+% of email messages sent or received (such as Eudora,
Netscape and Outlook), are crypto-cabable. Still, basically nobody uses
it.




-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sun Jan 28 12:48:01 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09556
	for <sip-archive@odin.ietf.org>; Sun, 28 Jan 2001 12:48:01 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D343E44399; Sun, 28 Jan 2001 11:48:08 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id DB64444336
	for <sip@lists.bell-labs.com>; Sun, 28 Jan 2001 11:47:00 -0500 (EST)
Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0SHkfK07326;
	Sun, 28 Jan 2001 11:46:41 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f0SHkfS08919;
	Sun, 28 Jan 2001 11:46:41 -0600 (CST)
Received: from ericsson.com (pc050184.exu.ericsson.se [138.85.50.184]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA05118; Sun, 28 Jan 2001 11:46:40 -0600 (CST)
Message-ID: <3A745ACE.1020806@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: ??? <hkjung@contela.com>
Cc: Rick Dean <siplist@fdd.com>, Rohan Mahy <rohan@cisco.com>,
        sip@lists.bell-labs.com
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
References: <5.0.0.25.2.20010117162639.01b82090@imop.cisco.com> <004a01c0890f$8b28de40$21171796@sktelecom.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 28 Jan 2001 11:45:50 -0600
Content-Transfer-Encoding: 7bit


??? wrote:

> Dear all.
> I am some curious about HANDOFF method.
> 
> I think, HANDOFF method is required when SIP terminal moves from one 
> network to other network.
> 
> In 3GPP TR23.821, the sentense,
> 
> " As a consequence, the behaviour of the multimedia call control server 
> (CSCF) can be the same whatever the access technology (radio or 
> wired-line). Multimedia call control/mobility management shall not be 
> aware of the access technology: the multimedia Call Control (CSCF) does 
> not handle notions such as Hand-Over, RA, "
> 
> It means that handoff is the problem of GGSN and SGSN not CSCF which 
> support SIP protocol. It is not the business of CSCF.
> Therefore I think HANDOFF method is not required at least 3GPP.
> What do you think about this?
> 

A couple of comments:

1) The SIP working group is not responsible for determining the
    applicability of various SIP extensions to the 3GPP architecture.
    This is the responsibility of 3GPP as they have the detailed
    knowledge of that architecture.

2) HANDOFF in the aforementioned draft does not address mobility
    management in the sense which you are thinking of. It is not
    about access level handoff, eg. handoff between SGSNs or the like.
    Because it is a call signalling mechanism it is best suited for
    call services (as mentioned in the draft). For example:

       * Call Transfer, both Attended and Unattended
       * Call Park/Un-Park
       * Multi-Stage Dialing
       * Operator Services
       * Conference Call Management
       * Call Pickup

/sean



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sun Jan 28 13:14:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09701
	for <sip-archive@odin.ietf.org>; Sun, 28 Jan 2001 13:14:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id BE9DA443AE; Sun, 28 Jan 2001 12:15:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 1B1A5443A8
	for <sip@lists.bell-labs.com>; Sun, 28 Jan 2001 12:14:47 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA02965;
	Sun, 28 Jan 2001 13:14:31 -0500 (EST)
Message-ID: <3A746187.CBD2A462@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Bryan Byerly <byerly@cisco.com>, sip@lists.bell-labs.com
References: <3A6C6667.EED68097@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: [Fwd: Announcements in SIP]
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 28 Jan 2001 13:14:31 -0500
Content-Transfer-Encoding: 7bit

Bryan Byerly wrote:
> 
> I'd appreciate your thoughts on annoucements.

I probably missed most of the discussion on this, but almost all SIP
clients have a textual display of at least two lines, so they can render
the 404 announcement as text. Thus, the lack of local announcements is
only a problem for gatewayed black phones (which doesn't make the
problem disappear, but qualifies the statement "no local announcement
capability"). 

Also, this is very similar to early media and can be handled by the
proxy instructing an RTSP server, for example, to send audio to the IP
address contained in the caller SDP. Override would presumably be
handled similar for all early media, if text-to-speech conversion is
used.

Finally, in case this hasn't been mentioned, 2543bis02 provides the
Error-Info header, which seems ideally suited to provide a reference to
further information, using either an RTSP, SIP or HTTP URL (or even a
data URL, if you don't mind longer messages). The header allows a
comma-separated list, so that the callee can provide a range of options
for the caller to choose from, depending on client capabilities and
human preferences. It does not seem unreasonable for a gateway to speak
HTTP and RTSP, for example, to retrieve such announcements. (SIP
soft/hard UAs such as PC software or SIP phones, as I said above, are
not likely to face this problem.)

Thus, I'm not exactly sure why this requires additional SIP mechanisms
or considerations.


> For this thread of discussion, we're talking about announcements which
> are played when an error occurred during call setup.  For instance, on
> 404, a message could be played "The URL you have dialed B...O...B. is
> not in service, please check the URL or dial the operator for
> assistance".
> 
> There are at least two desired behaviors w/r/t annoucements:
> Desired behavior 1: There should be a mechanism so that local
> annoucements override network annoucements.
> Desired behavior 2: There should be a mechanism so that announcements
> are not billable.
> 
> Like call forwarding features in SIP, there are implementable
> solutions to play annoucements using user agents or proxies.
> 
> In the diagrams below, A, B, and C are user agents, Po is an
> originating proxy and Pt is a terminating proxy.
> 
> User agent: Event based local announcement
> A                 Po             Pt
> |                  |              |
> |--INV Bob@B------>|              |
> |                  |              |
> |<-404-------------|              |
> |                  |              |
> A generates
> local audio
> indicating
> "The URL you have dialed B...O...B is not in service, please check the
> 
>  URL or dial the operator for assistance."
> 
> 
> Proxy: Event based call diversion (recursive)
> A                  Po             Pt        Announcement
>                                               Server
> |                  |              |             |
> |--INV Bob@B------>|              |             |
> |                  |--INV Bob@B-->|             |
> |                  |<-404---------|             |
> |            proxy implements     |             |
> |            call forward on 404  |             |
> |                  |--INV AnnServer------------>|
> |                  |  Diversion: Bob@B          |
> |                  |              |             |
> |<-200------------------------------------------|
> |<==="The URL you have dialed B...O...B is not==|
> |     in service, please check the URL or dial  |
> |     the operator for assistance"
> 
> 
> Both approaches are viable and there are advantages/disadvantages to
> each.  If all user agents supported local generation of announcements,
> then an event based call diversion solution may not be needed.
> However, in today's world, many user agent implementations do not have
> support for generating local announcements.
> 
> Advantages for "event based local announcements"
> a) requires no network bandwidth
> b) requires no annoucements server
> 
> Disadvantages for "event based local announcements"
> a) Not all SIP user agents support locally generated announcements
> b) provisioning issues for large-scale deployments. (i.e. If
> desirable, how would a network admin configure multi-vendor SIP phones
> in his net with certain announcements).
> 
> Advantages for "event based call diversion"
> a) Provides annoucement support in multi-vendor networks across all
> SIP user agents
> b) Provisioning is centralized at proxy and announcement server
> 
> Disadvantages for "event based call diversion"
> a) requires network bandwidth to play annoucements
> b) requires presence of an announcements server
> 
> I'm not interested in a holy war of which to use.  Each solution will
> be appropriate for certain network deployments.  There will soon be
> implementations of event based local annoucements and event based call
> diversion.  The more important issue is to define a mechanism to get
> desired feature interaction.
> 
> 
> 
> Desired behavior 1: There should be a mechanism so that local
> annoucements override network annoucements.
> 
> I would like the behavior that locally generated annoucements take
> precendence over proxy event based call diversion.  In other words,
> given a UA that is configured to play announcement X and proxy that is
> configured to divert to an announcement server to play message Y, I
> want X to be played.  i.e. I want the behavior of a smart UA to be
> able to override the behavior (provided by proxies in the network) to
> dumb UAs.
> 
> Unfortunately, Po gets a chance to divert the call first:
> Proxy: Event based call diversion (recursive)
> A                  Po             Pt         AnnServer
> |                  |              |             |
> |--INV Bob@B------>|              |             |
> |                  |--INV Bob@B-->|             |
> |                  |<-404---------|             |
> |            proxy implements     |             |
> |            call forward on 404  |             |
> |                  |--INV AnnServer------------>|
> |                  |  Diversion: Bob@B          |
> |                  |              |             |
> |<-200------------------------------------------|
> |<==="The URL you have dialed B...O...B is not==|
> |     in service, please check the URL or dial  |
> |     the operator for assistance"
> 
> Solution 1a: Non-recursive implementation of call diversion
> A possible solution would be to implement the diversion
> non-recursively:
> Proxy: Event based call diversion (non-recursive)
> A                  Po             Pt         AnnServer
> |                  |              |             |
> |--INV Bob@B------>|              |             |
> |                  |--INV Bob@B-->|             |
> |                  |<-404---------|             |
> |            proxy implements     |             |
> |            non-recursive        |             |
> |            call forward on 404  |             |
> |<-302-------------|              |             |
> |  Contact: AnnServer             |             |
> |  Diversion: Bob@B; reason=404   |             |
> |                  |              |             |
> |--INV AnnServer------------------------------->|
> |  Diversion: Bob@B; reason=404   |             |
> |                  |              |             |
> |<-200------------------------------------------|
> |<==="The URL you have dialed B...O...B is not==|
> |     in service, please check the URL or dial  |
> |     the operator for assistance"
> 
> then the feature interaction could be:
> A ignores 302s with Diversion header indicating reason codes for which
> A local generation of annoucements.
> Proxy: Event based call diversion (non-recursive)
> User agent: Event based local announcement (overriding 302s with
> already covered Diversion reason codes)
> A                  Po             Pt         AnnServer
> |                  |              |             |
> |--INV Bob@B------>|              |             |
> |                  |--INV Bob@B-->|             |
> |                  |<-404---------|             |
> |            proxy implements     |             |
> |            non-recursive        |             |
> |            call forward on 404  |             |
> |<-302-------------|              |             |
> |  Contact: AnnServer             |             |
> |  Diversion: Bob@B; reason=404   |             |
> |                  |              |             |
> A generates
> local audio
> indicating
> "The URL you have dialed B...O...B is not in service, please check the
> 
>  URL or dial the operator for assistance."
> 
> Solution 1b: "Supported: annoucements" header
> Another possible solution would be for smart UAs (that support
> announcements) to use a "Supported: annoucements" header.  This
> supported header would be used to indicate to proxies that they should
> not implement event based call forwarding (for annoucements):
> 
> Proxy: Event based call diversion (deferring implementation to UAC
> when "Supported: annoucements" is present)
> User agent: Event based local announcement
> A                 Po             Pt
> |                  |              |
> |--INV Bob@B------>|              |
> |  Supported: annoucements        |
> |                  |              |
> |<-404-------------|              |
> |                  |              |
> A generates
> local audio
> indicating
> "The URL you have dialed B...O...B is not in service, please check the
> 
>  URL or dial the operator for assistance."
> 
> 
> 
> Desired behavior 2:  There should be a mechanism so that announcements
> are not billable.
> 
> Another issue that has been raised w/r/t annoucements in networks
> where SIP signalling is billable.  The concern is that in SIP networks
> where 200 is used to write a start record, implementation of proxy
> event based call diversion might generate a charge.
> 
> Solution 2a: Play annoucements as early media
> One solution that has been proposed is to play annoucements as early
> media:
> 
> For example, recursively:
> A                  Po             Pt         AnnServer
> |                  |              |             |
> |--INV Bob@B------>|              |             |
> |                  |--INV Bob@B-->|             |
> |                  |<-404---------|             |
> |            proxy implements     |             |
> |            call forward on 404  |             |
> |                  |--INV AnnServer------------>|
> |                  |  Diversion: Bob@B          |
> |                  |              |             |
> |<-183------------------------------------------|
> |  Content-Disposition: session                 |
> |<==="The URL you have dialed B...O...B is not==|
> |     in service, please check the URL or dial  |
> |     the operator for assistance"
> |<-CANCEL---------------------------------------|
> |--200 (CANCEL)-------------------------------->|
> 
> or non-recursively:
> A                  Po             Pt         AnnServer
> |                  |              |             |
> |--INV Bob@B------>|              |             |
> |                  |--INV Bob@B-->|             |
> |                  |<-404---------|             |
> |            proxy implements     |             |
> |            non-recursive        |             |
> |            call forward on 404  |             |
> |<-302-------------|              |             |
> |  Contact: AnnServer             |             |
> |  Diversion: Bob@B; reason=404   |             |
> |                  |              |             |
> |--INV AnnServer------------------------------->|
> |  Diversion: Bob@B; reason=404   |             |
> |                  |              |             |
> |<-183------------------------------------------|
> |  Content-Disposition: session                 |
> |<==="The URL you have dialed B...O...B is not==|
> |     in service, please check the URL or dial  |
> |     the operator for assistance"
> |<-CANCEL---------------------------------------|
> |--200 (CANCEL)-------------------------------->|
> 
> Solution 2b: Backend billing system is aware of (non-billable)
> Announcement Server URL
> Another possible solution is that the URL of the AnnServer could be
> well-known to the backend billing system and that any accounting
> records written connection to the AnnServer would not be billed.
> 
> I'd like to solicit others' ideas, problems, and proposed solutions
> w/r/t annoucements in SIP.
> 
> I'm also looking for co-authors to write an I-D w/r/t announcements.
> If interested, please contact me directly at byerly@cisco.com.
> 
> thanks for your help,
> Bryan
> 
> Bryan J. Byerly
> byerly@cisco.com
> 
> 

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sun Jan 28 13:46:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09791
	for <sip-archive@odin.ietf.org>; Sun, 28 Jan 2001 13:46:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D828D443A4; Sun, 28 Jan 2001 12:47:07 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id 9089244336
	for <sip@lists.bell-labs.com>; Sun, 28 Jan 2001 12:46:43 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00460;
	Sun, 28 Jan 2001 10:46:18 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20708;
	Sun, 28 Jan 2001 10:46:18 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA29911;
	Sun, 28 Jan 2001 10:46:08 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
To: ??? <hkjung@contela.com>
Cc: Rick Dean <siplist@fdd.com>, Rohan Mahy <rohan@cisco.com>,
        sip@lists.bell-labs.com
In-Reply-To: "Your message with ID" <004a01c0890f$8b28de40$21171796@sktelecom.com>
Message-ID: <Roam.SIMC.2.0.6.980707566.15363.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 28 Jan 2001 10:46:06 -0800 (PST)

Ahhh, I see that the misuse of terminology is biting this WG in the a..

This isn't a handoff as you, or I, or anyone else involved in mobility
management understands it. It is rather a form of call transfer. You are
correct that the handoff will occur at the GGSN/SGSN.

I have asked that the WG refrain from using the term handoff, or handover,
given that the mobility folks will have serious issues with it (as they have
had with SIP Mobility, when it fact it is really portability). However, the WG
does not seem to be willing to listen to our requests :(

I suppose we will simply have to deal with the constant confusion we are
creating in the marketplace by abusing terminology.

PatC
> Dear all. 
> 
> I am some curious about HANDOFF method. 
> I think, HANDOFF method is required when SIP terminal moves from one network
> to other network. 
> 
> In 3GPP TR23.821, the sentense,
> " As a consequence, the behaviour of the multimedia call control server
> (CSCF) can be the same whatever the access technology (radio or wired-line).
> Multimedia call control/mobility management shall not be aware of the access
> technology: the multimedia Call Control (CSCF) does not handle notions such
> as Hand-Over, RA, "
> 
> It means that handoff is the problem of GGSN and SGSN not CSCF which support
> SIP protocol. It is not the business of CSCF. 
> 
> Therefore I think HANDOFF method is not required at least 3GPP. 
> 
> What do you think about this? 
> 


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sun Jan 28 14:56:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10208
	for <sip-archive@odin.ietf.org>; Sun, 28 Jan 2001 14:56:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9D9A0443A0; Sun, 28 Jan 2001 13:57:07 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id B991E44336
	for <sip@lists.bell-labs.com>; Sun, 28 Jan 2001 13:56:32 -0500 (EST)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA27899;
	Sun, 28 Jan 2001 11:56:30 -0800 (PST)
Received: from sony-laptop (rmahy-dsl4.cisco.com [10.19.53.125])
	by imop.cisco.com (Mirapoint)
	with SMTP id AAI69548;
	Sun, 28 Jan 2001 11:56:05 -0800 (PST)
Message-Id: <4.1.20010128115758.00b37a40@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>, ??? <hkjung@contela.com>
From: Rohan Mahy <rohan@cisco.com>
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
Cc: Rick Dean <siplist@fdd.com>, sip@lists.bell-labs.com
In-Reply-To: <Roam.SIMC.2.0.6.980707566.15363.pcalhoun@nasnfs>
References: <"Your message with ID" <004a01c0890f$8b28de40$21171796@sktelecom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 28 Jan 2001 12:02:01 -0800

Patrice,

1) the HANDOFF proposal is an individual submission to the SIP working
group.  People can propose whatever names they like.  The IETF WG as a
whole had nothing to do with the selection of the method name.

2) We are beginning to run out of names to describe the various features,
and even the different variations on some fairly basic functionality.
Someone has a problem with every name which is proposed, so please propose
an alternate, or understand that the english language is full of words with
multiple, somtimes confusing names, and that is just the way it is.

thanks,
-rohan


At 10:46 AM 1/28/01 , Patrice Calhoun wrote:
>Ahhh, I see that the misuse of terminology is biting this WG in the a..
>
>This isn't a handoff as you, or I, or anyone else involved in mobility
>management understands it. It is rather a form of call transfer. You are
>correct that the handoff will occur at the GGSN/SGSN.
>
>I have asked that the WG refrain from using the term handoff, or handover,
>given that the mobility folks will have serious issues with it (as they have
>had with SIP Mobility, when it fact it is really portability). However, the WG
>does not seem to be willing to listen to our requests :(
>
>I suppose we will simply have to deal with the constant confusion we are
>creating in the marketplace by abusing terminology.
>
>PatC
>> Dear all. 
>> 
>> I am some curious about HANDOFF method. 
>> I think, HANDOFF method is required when SIP terminal moves from one network
>> to other network. 
>> 
>> In 3GPP TR23.821, the sentense,
>> " As a consequence, the behaviour of the multimedia call control server
>> (CSCF) can be the same whatever the access technology (radio or wired-line).
>> Multimedia call control/mobility management shall not be aware of the access
>> technology: the multimedia Call Control (CSCF) does not handle notions such
>> as Hand-Over, RA, "
>> 
>> It means that handoff is the problem of GGSN and SGSN not CSCF which support
>> SIP protocol. It is not the business of CSCF. 
>> 
>> Therefore I think HANDOFF method is not required at least 3GPP. 
>> 
>> What do you think about this? 
>> 
>


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sun Jan 28 16:19:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10480
	for <sip-archive@odin.ietf.org>; Sun, 28 Jan 2001 16:19:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9A23744337; Sun, 28 Jan 2001 15:20:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id B35B944337
	for <sip@lists.bell-labs.com>; Sun, 28 Jan 2001 15:19:06 -0500 (EST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA14299;
	Sun, 28 Jan 2001 13:18:33 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAT00855;
	Sun, 28 Jan 2001 13:18:19 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA28344; Sun, 28 Jan 2001 13:18:19 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14964.35995.661716.307179@thomasm-u1.cisco.com>
To: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: Michael Thomas <mat@cisco.com>,
        Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        christopher.a.martin@wcom.com,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] T2 and 182 Queued
In-Reply-To: <3A743684.70213936@cs.columbia.edu>
References: <Roam.SIMC.2.0.6.980455149.5856.pcalhoun@nasnfs>
	<3A7092A2.21DD6514@cs.columbia.edu>
	<14961.44530.289344.512637@thomasm-u1.cisco.com>
	<3A72AFA5.7318CB11@cs.columbia.edu>
	<14963.29338.544692.870760@thomasm-u1.cisco.com>
	<3A73A088.1C6DA076@cs.columbia.edu>
	<14963.31164.232162.833103@thomasm-u1.cisco.com>
	<3A73AF3A.D3A983BB@cs.columbia.edu>
	<14963.37129.775893.628640@thomasm-u1.cisco.com>
	<3A743684.70213936@cs.columbia.edu>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 28 Jan 2001 13:18:19 -0800 (PST)
Content-Transfer-Encoding: 7bit

Henning G. Schulzrinne writes:
 > Michael Thomas wrote:
 > > The cost of implementing strong crypto on a
 > > consumer class box is probably less than $1. Maybe
 > 
 > This is bogus. Have you tried to actually built one of those boxes? I
 > have and I know the prices for SRAM and DRAM, which are still major
 > components of the end system cost.

   Yes, as a matter of fact I have. I just looked on Pricewatch
   and ram seems to be going for about $.33/M and flash is going
   about $1-2/M. I just size'd pluto and klips and got about 400k.
   An embedded system could easily shave quite a bit of that down,
   but even if it didn't we're talking about less than $1 _retail_
   cost.
   
 > > less than $.50. Moore's law will make the cost of
 > > crypto an utterly insignificant cost in the
 > > future. Also: MEGACO and MGCP mandate the use of
 > > IPsec, and the main feedback there was the worry
 > 
 > Megaco and MGCP are also almost exclusively run without IPsec right now
 > (Apparently, they aren't used all that much, but that's a separate
 > problem). 

   The IETF isn't the protocol police, &tc. Are you
   saying that MEGAGO/MGCP should just face reality
   and put - oh say - digest authentication in too?

 > Plus, they are fixed-association devices across a single
 > network hop, so none of the difficulties we're discussing here apply.

   May I ask how you plan to do/scale cross realm Digest
   since you're throwing the PKI scaling spectre around?
 
 > > Digest is worse than nothing at all (Basic at
 > > least doesn't cop an attitude that it's anything
 > > less than inadequate): as currently -- and likely
 > > forever -- implemented does not provide basic
 > > security features like replay protection,
 > 
 > You keep repeating this, but that still doesn't make it correct.

   \/\/hatever. Be my guest. Build insecure boxes for
   specious reasons. Declare the problem intractable
   and substitute non-scalable fake security instead.
   Maybe we can have a great big group hug after we
   properly fawn over the emperor's new cloths.

		 Mike

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Sun Jan 28 19:18:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10991
	for <sip-archive@odin.ietf.org>; Sun, 28 Jan 2001 19:18:51 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 0644744337; Sun, 28 Jan 2001 18:19:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by lists.bell-labs.com (Postfix) with ESMTP id 7FA7B44336
	for <sip@lists.bell-labs.com>; Sun, 28 Jan 2001 18:18:21 -0500 (EST)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id RAA09158 for <sip@lists.bell-labs.com>; Sun, 28 Jan 2001 17:17:35 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id RAA00419 for <sip@lists.bell-labs.com>; Sun, 28 Jan 2001 17:17:35 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2651.58)
	id <DG4K73YZ>; Sun, 28 Jan 2001 18:17:35 -0600
Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8ABC@il27exm02.cig.mot.com>
From: Baniel Uri-CUB001 <Uri.Baniel@motorola.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="ISO-8859-1"
Subject: [SIP] Decoding the SIP URL
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Sun, 28 Jan 2001 18:17:33 -0600

Say a UAC gets the following SIP URL from its user in the 'To' and 'request
URI' fields: "t.watson@ieee.org".
How does the UAC 'guess' if 'ieee.org' refer to a specific host or a domain?
Looks like according Bis02 para 1.4.2, the UAC tries to get DNS SRV record
first, and then A record if the former query has failed. Is that true? If
yes, looks like according the DNS RFC, one may issue a DNS query w/ multiple
types (e.g. _sip, a, aaaa) and act based on the response.
Was that the intention of Bis?

============================================
Uri.Baniel@motorola.com, 
Tel: (847) 632 4616; Fax: (847) 632 3963; 
============================================


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 29 02:30:59 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27936
	for <sip-archive@odin.ietf.org>; Mon, 29 Jan 2001 02:30:58 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E057E44337; Mon, 29 Jan 2001 01:31:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 9EFCB44336
	for <sip@lists.bell-labs.com>; Mon, 29 Jan 2001 01:30:41 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA02394;
	Mon, 29 Jan 2001 02:33:11 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9K261C>; Mon, 29 Jan 2001 02:26:48 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB21E@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'orenl@zapex.co.il'" <orenl@zapex.co.il>, sip@lists.bell-labs.com
Subject: RE: [SIP] Bake-Off logs
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 29 Jan 2001 02:26:47 -0500

Questions as this should be addressed to the sip implementors list,
sip-implementors@cs.columbia.edu. 

To answer, there are no logs generally maintained at the bakeoff. INdividual
participants may collect them, but thats an individual decision.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

> -----Original Message-----
> From: Oren Louidor [mailto:orenl@zapex.co.il]
> Sent: Saturday, January 27, 2001 5:10 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Bake-Off logs
> 
> 
> Also,
> Where can I get the logs of one of the bake-offs that took place ?
> 
> Oren.
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 29 03:00:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA28066
	for <sip-archive@odin.ietf.org>; Mon, 29 Jan 2001 03:00:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 585C94433E; Mon, 29 Jan 2001 02:01:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 7E38E44336
	for <sip@lists.bell-labs.com>; Mon, 29 Jan 2001 02:00:14 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA02456;
	Mon, 29 Jan 2001 03:02:55 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9K261R>; Mon, 29 Jan 2001 02:56:32 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB21F@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        Bryan Byerly <byerly@cisco.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Re: [Fwd: Announcements in SIP]
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 29 Jan 2001 02:56:28 -0500

I've somehow only gotten a subset of the messages in this thread, so I'm a
bit confused as to what exactly has been proposed.

SIP has a way to handle in-band announcements, both before and after a call
is setup. SIP also has a way to redirect a caller to fetch error information
from a URL. All of this is in bis-02. 

Bryan has asked for, in addition to this:

> Desired behavior 1: There should be a mechanism so that local
> annoucements override network annoucements.

I recall somewhere in this thread that there were proposals for things like
SUpported: announcements, or something like that, which indicated whether
the UA wanted to play local announcements or not. I think thats an awful
idea. Ultimately, the issue comes down to control. If control resides with
proxies in the network, the call will be answered and/or early media is
used, and that is what the UA hears. If the call is redirected or responded
to with an Error-Info back to the caller, then control resides in the UA,
and it can play a local announcement. We already have a general purpose
mechanism that allows a UA to request to remain in control - caller
preferences. The request-disposition header can ask for proxy or redirect
for this call:

Request-Disposition: redirect

this would have the effect of allowing the UA to control the local
announcements. I'd rather use a general purpose mechanism like this than
invent some one specifically for announcements.

Bryan has also asked for:
> > Desired behavior 2: There should be a mechanism so that 
> announcements
> > are not billable.

This has nothing to do with the protocol. A service provider bills for
services. If they answer a call and play some kind of error announcement,
its that providers responsibility to bill or not bill accordingly. I don't
see what more needs be done in SIP for this.

-Jonathan R.


---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Sunday, January 28, 2001 1:15 PM
> To: Bryan Byerly; sip@lists.bell-labs.com
> Subject: [SIP] Re: [Fwd: Announcements in SIP]
> 
> 
> Bryan Byerly wrote:
> > 
> > I'd appreciate your thoughts on annoucements.
> 
> I probably missed most of the discussion on this, but almost all SIP
> clients have a textual display of at least two lines, so they 
> can render
> the 404 announcement as text. Thus, the lack of local announcements is
> only a problem for gatewayed black phones (which doesn't make the
> problem disappear, but qualifies the statement "no local announcement
> capability"). 
> 
> Also, this is very similar to early media and can be handled by the
> proxy instructing an RTSP server, for example, to send audio to the IP
> address contained in the caller SDP. Override would presumably be
> handled similar for all early media, if text-to-speech conversion is
> used.
> 
> Finally, in case this hasn't been mentioned, 2543bis02 provides the
> Error-Info header, which seems ideally suited to provide a 
> reference to
> further information, using either an RTSP, SIP or HTTP URL (or even a
> data URL, if you don't mind longer messages). The header allows a
> comma-separated list, so that the callee can provide a range 
> of options
> for the caller to choose from, depending on client capabilities and
> human preferences. It does not seem unreasonable for a 
> gateway to speak
> HTTP and RTSP, for example, to retrieve such announcements. (SIP
> soft/hard UAs such as PC software or SIP phones, as I said above, are
> not likely to face this problem.)
> 
> Thus, I'm not exactly sure why this requires additional SIP mechanisms
> or considerations.
> 
> 
> > For this thread of discussion, we're talking about 
> announcements which
> > are played when an error occurred during call setup.  For 
> instance, on
> > 404, a message could be played "The URL you have dialed 
> B...O...B. is
> > not in service, please check the URL or dial the operator for
> > assistance".
> > 
> > There are at least two desired behaviors w/r/t annoucements:
> > Desired behavior 1: There should be a mechanism so that local
> > annoucements override network annoucements.
> > Desired behavior 2: There should be a mechanism so that 
> announcements
> > are not billable.
> > 
> > Like call forwarding features in SIP, there are implementable
> > solutions to play annoucements using user agents or proxies.
> > 
> > In the diagrams below, A, B, and C are user agents, Po is an
> > originating proxy and Pt is a terminating proxy.
> > 
> > User agent: Event based local announcement
> > A                 Po             Pt
> > |                  |              |
> > |--INV Bob@B------>|              |
> > |                  |              |
> > |<-404-------------|              |
> > |                  |              |
> > A generates
> > local audio
> > indicating
> > "The URL you have dialed B...O...B is not in service, 
> please check the
> > 
> >  URL or dial the operator for assistance."
> > 
> > 
> > Proxy: Event based call diversion (recursive)
> > A                  Po             Pt        Announcement
> >                                               Server
> > |                  |              |             |
> > |--INV Bob@B------>|              |             |
> > |                  |--INV Bob@B-->|             |
> > |                  |<-404---------|             |
> > |            proxy implements     |             |
> > |            call forward on 404  |             |
> > |                  |--INV AnnServer------------>|
> > |                  |  Diversion: Bob@B          |
> > |                  |              |             |
> > |<-200------------------------------------------|
> > |<==="The URL you have dialed B...O...B is not==|
> > |     in service, please check the URL or dial  |
> > |     the operator for assistance"
> > 
> > 
> > Both approaches are viable and there are advantages/disadvantages to
> > each.  If all user agents supported local generation of 
> announcements,
> > then an event based call diversion solution may not be needed.
> > However, in today's world, many user agent implementations 
> do not have
> > support for generating local announcements.
> > 
> > Advantages for "event based local announcements"
> > a) requires no network bandwidth
> > b) requires no annoucements server
> > 
> > Disadvantages for "event based local announcements"
> > a) Not all SIP user agents support locally generated announcements
> > b) provisioning issues for large-scale deployments. (i.e. If
> > desirable, how would a network admin configure multi-vendor 
> SIP phones
> > in his net with certain announcements).
> > 
> > Advantages for "event based call diversion"
> > a) Provides annoucement support in multi-vendor networks across all
> > SIP user agents
> > b) Provisioning is centralized at proxy and announcement server
> > 
> > Disadvantages for "event based call diversion"
> > a) requires network bandwidth to play annoucements
> > b) requires presence of an announcements server
> > 
> > I'm not interested in a holy war of which to use.  Each 
> solution will
> > be appropriate for certain network deployments.  There will soon be
> > implementations of event based local annoucements and event 
> based call
> > diversion.  The more important issue is to define a mechanism to get
> > desired feature interaction.
> > 
> > 
> > 
> > Desired behavior 1: There should be a mechanism so that local
> > annoucements override network annoucements.
> > 
> > I would like the behavior that locally generated annoucements take
> > precendence over proxy event based call diversion.  In other words,
> > given a UA that is configured to play announcement X and 
> proxy that is
> > configured to divert to an announcement server to play message Y, I
> > want X to be played.  i.e. I want the behavior of a smart UA to be
> > able to override the behavior (provided by proxies in the 
> network) to
> > dumb UAs.
> > 
> > Unfortunately, Po gets a chance to divert the call first:
> > Proxy: Event based call diversion (recursive)
> > A                  Po             Pt         AnnServer
> > |                  |              |             |
> > |--INV Bob@B------>|              |             |
> > |                  |--INV Bob@B-->|             |
> > |                  |<-404---------|             |
> > |            proxy implements     |             |
> > |            call forward on 404  |             |
> > |                  |--INV AnnServer------------>|
> > |                  |  Diversion: Bob@B          |
> > |                  |              |             |
> > |<-200------------------------------------------|
> > |<==="The URL you have dialed B...O...B is not==|
> > |     in service, please check the URL or dial  |
> > |     the operator for assistance"
> > 
> > Solution 1a: Non-recursive implementation of call diversion
> > A possible solution would be to implement the diversion
> > non-recursively:
> > Proxy: Event based call diversion (non-recursive)
> > A                  Po             Pt         AnnServer
> > |                  |              |             |
> > |--INV Bob@B------>|              |             |
> > |                  |--INV Bob@B-->|             |
> > |                  |<-404---------|             |
> > |            proxy implements     |             |
> > |            non-recursive        |             |
> > |            call forward on 404  |             |
> > |<-302-------------|              |             |
> > |  Contact: AnnServer             |             |
> > |  Diversion: Bob@B; reason=404   |             |
> > |                  |              |             |
> > |--INV AnnServer------------------------------->|
> > |  Diversion: Bob@B; reason=404   |             |
> > |                  |              |             |
> > |<-200------------------------------------------|
> > |<==="The URL you have dialed B...O...B is not==|
> > |     in service, please check the URL or dial  |
> > |     the operator for assistance"
> > 
> > then the feature interaction could be:
> > A ignores 302s with Diversion header indicating reason 
> codes for which
> > A local generation of annoucements.
> > Proxy: Event based call diversion (non-recursive)
> > User agent: Event based local announcement (overriding 302s with
> > already covered Diversion reason codes)
> > A                  Po             Pt         AnnServer
> > |                  |              |             |
> > |--INV Bob@B------>|              |             |
> > |                  |--INV Bob@B-->|             |
> > |                  |<-404---------|             |
> > |            proxy implements     |             |
> > |            non-recursive        |             |
> > |            call forward on 404  |             |
> > |<-302-------------|              |             |
> > |  Contact: AnnServer             |             |
> > |  Diversion: Bob@B; reason=404   |             |
> > |                  |              |             |
> > A generates
> > local audio
> > indicating
> > "The URL you have dialed B...O...B is not in service, 
> please check the
> > 
> >  URL or dial the operator for assistance."
> > 
> > Solution 1b: "Supported: annoucements" header
> > Another possible solution would be for smart UAs (that support
> > announcements) to use a "Supported: annoucements" header.  This
> > supported header would be used to indicate to proxies that 
> they should
> > not implement event based call forwarding (for annoucements):
> > 
> > Proxy: Event based call diversion (deferring implementation to UAC
> > when "Supported: annoucements" is present)
> > User agent: Event based local announcement
> > A                 Po             Pt
> > |                  |              |
> > |--INV Bob@B------>|              |
> > |  Supported: annoucements        |
> > |                  |              |
> > |<-404-------------|              |
> > |                  |              |
> > A generates
> > local audio
> > indicating
> > "The URL you have dialed B...O...B is not in service, 
> please check the
> > 
> >  URL or dial the operator for assistance."
> > 
> > 
> > 
> > Desired behavior 2:  There should be a mechanism so that 
> announcements
> > are not billable.
> > 
> > Another issue that has been raised w/r/t annoucements in networks
> > where SIP signalling is billable.  The concern is that in 
> SIP networks
> > where 200 is used to write a start record, implementation of proxy
> > event based call diversion might generate a charge.
> > 
> > Solution 2a: Play annoucements as early media
> > One solution that has been proposed is to play annoucements as early
> > media:
> > 
> > For example, recursively:
> > A                  Po             Pt         AnnServer
> > |                  |              |             |
> > |--INV Bob@B------>|              |             |
> > |                  |--INV Bob@B-->|             |
> > |                  |<-404---------|             |
> > |            proxy implements     |             |
> > |            call forward on 404  |             |
> > |                  |--INV AnnServer------------>|
> > |                  |  Diversion: Bob@B          |
> > |                  |              |             |
> > |<-183------------------------------------------|
> > |  Content-Disposition: session                 |
> > |<==="The URL you have dialed B...O...B is not==|
> > |     in service, please check the URL or dial  |
> > |     the operator for assistance"
> > |<-CANCEL---------------------------------------|
> > |--200 (CANCEL)-------------------------------->|
> > 
> > or non-recursively:
> > A                  Po             Pt         AnnServer
> > |                  |              |             |
> > |--INV Bob@B------>|              |             |
> > |                  |--INV Bob@B-->|             |
> > |                  |<-404---------|             |
> > |            proxy implements     |             |
> > |            non-recursive        |             |
> > |            call forward on 404  |             |
> > |<-302-------------|              |             |
> > |  Contact: AnnServer             |             |
> > |  Diversion: Bob@B; reason=404   |             |
> > |                  |              |             |
> > |--INV AnnServer------------------------------->|
> > |  Diversion: Bob@B; reason=404   |             |
> > |                  |              |             |
> > |<-183------------------------------------------|
> > |  Content-Disposition: session                 |
> > |<==="The URL you have dialed B...O...B is not==|
> > |     in service, please check the URL or dial  |
> > |     the operator for assistance"
> > |<-CANCEL---------------------------------------|
> > |--200 (CANCEL)-------------------------------->|
> > 
> > Solution 2b: Backend billing system is aware of (non-billable)
> > Announcement Server URL
> > Another possible solution is that the URL of the AnnServer could be
> > well-known to the backend billing system and that any accounting
> > records written connection to the AnnServer would not be billed.
> > 
> > I'd like to solicit others' ideas, problems, and proposed solutions
> > w/r/t annoucements in SIP.
> > 
> > I'm also looking for co-authors to write an I-D w/r/t announcements.
> > If interested, please contact me directly at byerly@cisco.com.
> > 
> > thanks for your help,
> > Bryan
> > 
> > Bryan J. Byerly
> > byerly@cisco.com
> > 
> > 
> 
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 29 03:07:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA28090
	for <sip-archive@odin.ietf.org>; Mon, 29 Jan 2001 03:07:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 15F3E4434E; Mon, 29 Jan 2001 02:08:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id C9E694434C
	for <sip@lists.bell-labs.com>; Mon, 29 Jan 2001 02:07:01 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA02513;
	Mon, 29 Jan 2001 03:09:38 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9K2610>; Mon, 29 Jan 2001 03:03:15 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB221@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Rick Dean'" <siplist@fdd.com>, Bryan Byerly <byerly@cisco.com>
Cc: sip@lists.bell-labs.com, aaron_madsen@3com.com
Subject: RE: [SIP] Announcements in SIP (401 & 407 contact)
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 29 Jan 2001 03:03:14 -0500



 

> -----Original Message-----
> From: Rick Dean [mailto:siplist@fdd.com]
> Sent: Wednesday, January 24, 2001 12:34 PM
> To: Bryan Byerly
> Cc: sip@lists.bell-labs.com; aaron_madsen@3com.com
> Subject: Re: [SIP] Announcements in SIP (401 & 407 contact)
> 
> 
> 
> Sadly, I just discovered the hard way that the contact
> header of a 407 and 401 (authentication required) response
> is like 3xx not 200.  
> 
> From: draft-ietf-sip-rfc2543bis-02.txt
> >        4xx, 5xx and 6xx responses: The Contact response-header field
> >             can be used with a 4xx, 5xx or 6xx response to 
> indicate the
> >             location where additional information about the 
> error can
> >             be found.
> 
> I suppose this also means these response cannot form a route.
> 
> Does anyone use them in this fashon for 401 and 407?  
> 
> --
> Rick
> 

There is a general issue here of whether record-routing makes sense for
non-200 responses (since Contact in a 200 has a record-route type of
semantic). I have come to the conclusion that usage of record-route, and
thus of a 200-style semantic to contact, does NOT make sense anywhere but
200 class responses. The reason is that the notion of a route is tied to the
notion of a session over which the route is used. Only 200 sets up a
session. Even things like 401/407, which look like a session is there of
sorts, don't have one. Authorization in sip is stateless. Its perfectly fine
for a request to go to one server, for it to get a challenge in response,
and for a resubmitted request (now with credentials) to go to a different
server in that same realm. Works quite fine; better, in fact, than if you
record-route.

-Jonathan R.


---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 29 07:39:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA00608
	for <sip-archive@odin.ietf.org>; Mon, 29 Jan 2001 07:39:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id F196044337; Mon, 29 Jan 2001 06:40:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web10309.mail.yahoo.com (web10309.mail.yahoo.com [216.136.173.151])
	by lists.bell-labs.com (Postfix) with SMTP id 07E1744336
	for <sip@lists.bell-labs.com>; Mon, 29 Jan 2001 06:39:14 -0500 (EST)
Message-ID: <20010129123900.73524.qmail@web10309.mail.yahoo.com>
Received: from [203.200.4.109] by web10309.mail.yahoo.com; Mon, 29 Jan 2001 04:39:00 PST
From: james jack <sipjames@yahoo.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] One consulation on multiple Contact headers in INVITE request
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 29 Jan 2001 04:39:00 -0800 (PST)

Dear All:
   I have one question to consult,
in INVITE request, if there is multiple 
Contact headers, should this be valid?
   In my opinion, I think it is valid,
but this may cause problem, that is ,
when the callee send BYE request for the 
established call between caller with multiple 
contacts, then the proxy will fork this request?
   Could anyone give me some suggestion?
   Best regards!
                   Yours:james




__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices. 
http://auctions.yahoo.com/

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 29 07:54:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01064
	for <sip-archive@odin.ietf.org>; Mon, 29 Jan 2001 07:54:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 4CB004434A; Mon, 29 Jan 2001 06:55:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id BC8D344346
	for <sip@lists.bell-labs.com>; Mon, 29 Jan 2001 06:54:00 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 29 Jan 2001 12:53:47 UT
Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef)
	id MAA15374; Mon, 29 Jan 2001 12:52:34 GMT
From: "Jo Hornsby" <jhornsby@ubiquity.net>
To: "james jack" <sipjames@yahoo.com>, <sip@lists.bell-labs.com>
Subject: RE: [SIP] One consulation on multiple Contact headers in INVITE request
Message-ID: <000f01c089f2$597d78e0$4e34c3c1@ubiquity.co.uk>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-reply-to: <20010129123900.73524.qmail@web10309.mail.yahoo.com>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Importance: Normal
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 29 Jan 2001 12:52:34 -0000
Content-Transfer-Encoding: 7bit

James Jack wrote:
>    I have one question to consult,
> in INVITE request, if there is multiple 
> Contact headers, should this be valid?

No.  There should be stricly one Contact header in an INVITE
request, and correspondingly, one Contact header in a 2xx to
an INVITE.

HTH,


 - Jo.


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 29 08:49:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02665
	for <sip-archive@odin.ietf.org>; Mon, 29 Jan 2001 08:49:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 07FCF44338; Mon, 29 Jan 2001 07:50:07 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by lists.bell-labs.com (Postfix) with ESMTP id DFF3944336
	for <sip@lists.bell-labs.com>; Mon, 29 Jan 2001 07:49:01 -0500 (EST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04780;
	Mon, 29 Jan 2001 05:48:36 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21570;
	Mon, 29 Jan 2001 05:48:35 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id FAA06957;
	Mon, 29 Jan 2001 05:48:33 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: RE: [SIP] Announcements in SIP (401 & 407 contact)
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Rick Dean'" <siplist@fdd.com>, Bryan Byerly <byerly@cisco.com>,
        sip@lists.bell-labs.com, aaron_madsen@3com.com
In-Reply-To: "Your message with ID" <B65B4F8437968F488A01A940B21982BF9AB221@DYN-EXCH-001.dynamicsoft.com>
Message-ID: <Roam.SIMC.2.0.6.980776114.14588.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 29 Jan 2001 05:48:34 -0800 (PST)

> There is a general issue here of whether record-routing makes sense for
> non-200 responses (since Contact in a 200 has a record-route type of
> semantic). I have come to the conclusion that usage of record-route, and
> thus of a 200-style semantic to contact, does NOT make sense anywhere but
> 200 class responses. The reason is that the notion of a route is tied to the
> notion of a session over which the route is used. Only 200 sets up a
> session. Even things like 401/407, which look like a session is there of
> sorts, don't have one. Authorization in sip is stateless. Its perfectly fine
> for a request to go to one server, for it to get a challenge in response,
> and for a resubmitted request (now with credentials) to go to a different
> server in that same realm. Works quite fine; better, in fact, than if you
> record-route.

I appologize if this is obvious, and just a misunderstanding on my part on how
SIP works, but how would stateless challenges be issued, and the response be
returned to a different server. I would assume that a challenge has to be
non-replayable, and therefore the server generating the challenge wants to be
sure that the response corresponds to a challenge that was recently issued.

How is this guaranteed, if servers are stateless (meaning, I guess, they do
not keep track of challenges issued), and the response is not guaranteed to
hit the same server that issued the challenge.

One way, I suppose, is to define the format of the challenge to include a
timestamp.

PatC


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 29 10:25:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03828
	for <sip-archive@odin.ietf.org>; Mon, 29 Jan 2001 10:25:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 599C044341; Mon, 29 Jan 2001 09:26:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
	by lists.bell-labs.com (Postfix) with ESMTP id 18A3C44336
	for <sip@lists.bell-labs.com>; Mon, 29 Jan 2001 09:25:04 -0500 (EST)
Received: from gab200r1.ems.att.com ([135.37.94.32])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f0TFOej08269;
	Mon, 29 Jan 2001 10:24:40 -0500 (EST)
Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id KAA15739; Mon, 29 Jan 2001 10:23:41 -0500 (EST)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19)
	id <DHKSM7Y6>; Mon, 29 Jan 2001 10:24:39 -0500
Message-ID: <E5B80B001D76D211879C00E02910776107CEA9C2@njc240po05.mt.att.com>
From: "Roy, Radhika R, ALCOO" <rrroy@att.com>
To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>, ??? <hkjung@contela.com>
Cc: Rick Dean <siplist@fdd.com>, Rohan Mahy <rohan@cisco.com>,
        sip@lists.bell-labs.com
Subject: RE: [SIP] draft-ietf-sip-handoff-00pre8.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 29 Jan 2001 10:24:37 -0500

Yes, as PatC pointed out, the term "HANDOFF" is creating a constant
confusion.
I, like many others, also point this to the WG for consideration.

Radhika R. Roy
AT&T

-----Original Message-----
From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com]
Sent: Sunday, January 28, 2001 1:46 PM
To: ???
Cc: Rick Dean; Rohan Mahy; sip@lists.bell-labs.com
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt


Ahhh, I see that the misuse of terminology is biting this WG in the a..

This isn't a handoff as you, or I, or anyone else involved in mobility
management understands it. It is rather a form of call transfer. You are
correct that the handoff will occur at the GGSN/SGSN.

I have asked that the WG refrain from using the term handoff, or handover,
given that the mobility folks will have serious issues with it (as they have
had with SIP Mobility, when it fact it is really portability). However, the
WG
does not seem to be willing to listen to our requests :(

I suppose we will simply have to deal with the constant confusion we are
creating in the marketplace by abusing terminology.

PatC
> Dear all. 
> 
> I am some curious about HANDOFF method. 
> I think, HANDOFF method is required when SIP terminal moves from one
network
> to other network. 
> 
> In 3GPP TR23.821, the sentense,
> " As a consequence, the behaviour of the multimedia call control server
> (CSCF) can be the same whatever the access technology (radio or
wired-line).
> Multimedia call control/mobility management shall not be aware of the
access
> technology: the multimedia Call Control (CSCF) does not handle notions
such
> as Hand-Over, RA, "
> 
> It means that handoff is the problem of GGSN and SGSN not CSCF which
support
> SIP protocol. It is not the business of CSCF. 
> 
> Therefore I think HANDOFF method is not required at least 3GPP. 
> 
> What do you think about this? 
> 


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 29 10:33:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03937
	for <sip-archive@odin.ietf.org>; Mon, 29 Jan 2001 10:33:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1F5784435C; Mon, 29 Jan 2001 09:34:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by lists.bell-labs.com (Postfix) with ESMTP id EA4B94435B
	for <sip@lists.bell-labs.com>; Mon, 29 Jan 2001 09:33:09 -0500 (EST)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17489
	for <sip@lists.bell-labs.com>; Mon, 29 Jan 2001 07:32:55 -0800 (PST)
Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03573;
	Mon, 29 Jan 2001 07:32:50 -0800 (PST)
Received: from darius (darius.Eng.Sun.COM [10.6.84.105])
	by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA07862;
	Mon, 29 Jan 2001 07:32:48 -0800 (PST)
From: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
To: sip@lists.bell-labs.com
Cc: Pat Calhoun <pcalhoun@eng.sun.com>
In-Reply-To: "Your message with ID" <20010129095116.H1427@newman.frascone.com>
Message-ID: <Roam.SIMC.2.0.6.980782369.16989.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 29 Jan 2001 07:32:49 -0800 (PST)

I just love this spirit of cooperation :(

> 1) the HANDOFF proposal is an individual submission to the SIP working
> group.  People can propose whatever names they like.  The IETF WG as a
> whole had nothing to do with the selection of the method name.

Correct, but given that this I-D seems to have a fair amount of thrust, I
*assumed* that it will perhaps some day make it as a WG document. Of course,
if your intention is to leave it as an individual contribution, then please do
ignore all my comments.

> 
> 2) We are beginning to run out of names to describe the various features,
> and even the different variations on some fairly basic functionality.
> Someone has a problem with every name which is proposed, so please propose
> an alternate, 

Rohan, if I actually understood enough about your I-D to propose an
intelligent name, then I would. It does concern me that more than one person
has commented on the fact that the name is not appropriate, and in both cases
we were dismissed.

However, in order to get some closure on this one, how about I do propose a
name, which again may not be what you really want (or even what this I-D
does), and my proposal would be "transparent call transfer".

> or understand that the english language is full of words with
> multiple, somtimes confusing names, and that is just the way it is.

Right, but with the Oxford English Dictionary containing over half a million
words, I don't see much of an excuse of abusing known terms.

PatC


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 29 12:01:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05909
	for <sip-archive@odin.ietf.org>; Mon, 29 Jan 2001 12:01:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1EF0944337; Mon, 29 Jan 2001 11:02:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web10309.mail.yahoo.com (web10309.mail.yahoo.com [216.136.173.151])
	by lists.bell-labs.com (Postfix) with SMTP id E234344336
	for <sip@lists.bell-labs.com>; Mon, 29 Jan 2001 11:01:58 -0500 (EST)
Message-ID: <20010129170145.97182.qmail@web10309.mail.yahoo.com>
Received: from [203.200.4.109] by web10309.mail.yahoo.com; Mon, 29 Jan 2001 09:01:45 PST
From: james jack <sipjames@yahoo.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] Consultation on Stateless Proxy
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 29 Jan 2001 09:01:45 -0800 (PST)

Dear All:
   I have one question to consult, since
the stateless proxy does not produce the 
response for the coming reques,then for
example, if the coming SIP request without
essential information such as from, to; the
stateless proxy will not generate any response.
Then what the function for stateless proxy?
then is it necessary to add via information in
the Via headers in SIP request message? 
   Could any one give me some suggestion?
   Best regards!
                       Yours: james


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices. 
http://auctions.yahoo.com/

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 29 12:17:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06138
	for <sip-archive@odin.ietf.org>; Mon, 29 Jan 2001 12:17:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8FA5C4435B; Mon, 29 Jan 2001 11:18:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id D566E44358
	for <sip@lists.bell-labs.com>; Mon, 29 Jan 2001 11:17:04 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 29 Jan 2001 17:16:51 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id RAA09199; Mon, 29 Jan 2001 17:15:37 GMT
Message-ID: <3A75A539.E81DA001@ubiquity.net>
From: Neil Deason <ndeason@ubiquity.net>
Organization: Ubiquity Software Corporation Limited
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: james jack <sipjames@yahoo.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Consultation on Stateless Proxy
References: <20010129170145.97182.qmail@web10309.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 29 Jan 2001 17:15:37 +0000
Content-Transfer-Encoding: 7bit

Please address future consultations to the sip implementors list
-
sip-implementors@cs.columbia.edu. 

james jack wrote:
> 
> Dear All:
>    I have one question to consult, since
> the stateless proxy does not produce the
> response for the coming reques,then for
> example, if the coming SIP request without
> essential information such as from, to; the
> stateless proxy will not generate any response.
> Then what the function for stateless proxy?
> then is it necessary to add via information in
> the Via headers in SIP request message?
>    Could any one give me some suggestion?
>    Best regards!
>                        Yours: james

Messages that don't contain crucial info such as To, From,
Call-ID, Via can expect to be silently discarded by any 
server stateless or otherwise. 

Remember the terms stateless/stateful/proxy/redirect/
registrar are used to describe logical entities. Thus a 
single network server may choose to be stateful or 
stateless on a per transaction basis. Typically being 
stateless is seen as a way to aid performance.

Cheers,
Neil
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 29 14:36:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08402
	for <sip-archive@odin.ietf.org>; Mon, 29 Jan 2001 14:36:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D4EF944337; Mon, 29 Jan 2001 13:37:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by lists.bell-labs.com (Postfix) with ESMTP id 7B89F44336
	for <sip@lists.bell-labs.com>; Mon, 29 Jan 2001 13:36:22 -0500 (EST)
Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f0TJYOK28912;
	Mon, 29 Jan 2001 13:34:24 -0600 (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f0TJYNT12867;
	Mon, 29 Jan 2001 13:34:23 -0600 (CST)
Received: from ericsson.com (pc050184.exu.ericsson.se [138.85.50.184]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA22031; Mon, 29 Jan 2001 13:34:23 -0600 (CST)
Message-ID: <3A75C5C6.2000005@ericsson.com>
From: Sean Olson <sean.olson@ericsson.com>
Organization: Ericsson Inc.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; m18) Gecko/20001108 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: "Roy, Radhika R, ALCOO" <rrroy@att.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>, ??? <hkjung@contela.com>,
        Rick Dean <siplist@fdd.com>, Rohan Mahy <rohan@cisco.com>,
        sip@lists.bell-labs.com
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
References: <E5B80B001D76D211879C00E02910776107CEA9C2@njc240po05.mt.att.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 29 Jan 2001 13:34:30 -0600
Content-Transfer-Encoding: 7bit

The name can be confusing, I agree. But as with all
specifications, you need to read them in the appropriate
context. I personally find HANDOFF completely apropos for
this usage because it is a SIP method and because the
introduction in the draft does a good job of establishing
the scope and meaning of the method. If HANDOFF is
taboo, how about "TRANSFER"? Nevermind the confusing
part about the transfer draft defining REFER and the handoff
draft defining REFER :)

my two cents
/sean

Roy, Radhika R, ALCOO wrote:

> Yes, as PatC pointed out, the term "HANDOFF" is creating a constant
> confusion.
> I, like many others, also point this to the WG for consideration.
> 
> Radhika R. Roy
> AT&T
> 
> -----Original Message-----
> From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com]
> Sent: Sunday, January 28, 2001 1:46 PM
> To: ???
> Cc: Rick Dean; Rohan Mahy; sip@lists.bell-labs.com
> Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
> 
> 
> Ahhh, I see that the misuse of terminology is biting this WG in the a..
> 
> This isn't a handoff as you, or I, or anyone else involved in mobility
> management understands it. It is rather a form of call transfer. You are
> correct that the handoff will occur at the GGSN/SGSN.
> 
> I have asked that the WG refrain from using the term handoff, or handover,
> given that the mobility folks will have serious issues with it (as they have
> had with SIP Mobility, when it fact it is really portability). However, the
> WG
> does not seem to be willing to listen to our requests :(
> 
> I suppose we will simply have to deal with the constant confusion we are
> creating in the marketplace by abusing terminology.
> 
> PatC
> 
>> Dear all. 
>> 
>> I am some curious about HANDOFF method. 
>> I think, HANDOFF method is required when SIP terminal moves from one
> 
> network
> 
>> to other network. 
>> 
>> In 3GPP TR23.821, the sentense,
>> " As a consequence, the behaviour of the multimedia call control server
>> (CSCF) can be the same whatever the access technology (radio or
> 
> wired-line).
> 
>> Multimedia call control/mobility management shall not be aware of the
> 
> access
> 
>> technology: the multimedia Call Control (CSCF) does not handle notions
> 
> such
> 
>> as Hand-Over, RA, "
>> 
>> It means that handoff is the problem of GGSN and SGSN not CSCF which
> 
> support
> 
>> SIP protocol. It is not the business of CSCF. 
>> 
>> Therefore I think HANDOFF method is not required at least 3GPP. 
>> 
>> What do you think about this? 
>> 
> 
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 29 15:58:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09912
	for <sip-archive@odin.ietf.org>; Mon, 29 Jan 2001 15:58:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9779344337; Mon, 29 Jan 2001 14:59:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by lists.bell-labs.com (Postfix) with ESMTP id 39DFE44336
	for <sip@lists.bell-labs.com>; Mon, 29 Jan 2001 14:58:28 -0500 (EST)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12])
	by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA01456;
	Mon, 29 Jan 2001 15:58:11 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA13797;
	Mon, 29 Jan 2001 15:58:12 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id <DGK9X83M>; Mon, 29 Jan 2001 15:58:07 -0500
Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EDC7@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" <Brian.Rosen@marconi.com>
To: "'Michael Thomas'" <mat@cisco.com>,
        "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>,
        christopher.a.martin@wcom.com,
        "'Anders Kristensen'" <akristensen@dynamicsoft.com>,
        "'David Frascone'" <dave@frascone.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] T2 and 182 Queued
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 29 Jan 2001 15:58:03 -0500

First of all, could we please defuse the emotion here? It isn't helping.

Could we hear from the SIP phone/small gateway crowd:
	1. Have you actually tried to implement something along the lines of
			IPSEC or TLS in your product?
	2. Do you believe such an implementation to be a serious impediment
			to achieving goals of SIP Phones?
We have the PacketCable specs, which do in fact include this level of
crypto.
A quick look at a popular IPSEC stack shows around 400K of base code,
plus 1.6M for IKE and a policy manager, and less than 16K of RAM.  
That is with a lot of algorithms.  YMMV

I believe the benefits outweigh the costs for good crypto as a minimum
requirement, but I'm not counting $.01 at a time. 

Brian 


> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Sunday, January 28, 2001 4:18 PM
> To: Henning G. Schulzrinne
> Cc: Michael Thomas; Patrice Calhoun; christopher.a.martin@wcom.com;
> 'Anders Kristensen'; 'David Frascone'; sip@lists.bell-labs.com
> Subject: Re: [SIP] T2 and 182 Queued
> 
> 
> Henning G. Schulzrinne writes:
>  > Michael Thomas wrote:
>  > > The cost of implementing strong crypto on a
>  > > consumer class box is probably less than $1. Maybe
>  > 
>  > This is bogus. Have you tried to actually built one of 
> those boxes? I
>  > have and I know the prices for SRAM and DRAM, which are still major
>  > components of the end system cost.
> 
>    Yes, as a matter of fact I have. I just looked on Pricewatch
>    and ram seems to be going for about $.33/M and flash is going
>    about $1-2/M. I just size'd pluto and klips and got about 400k.
>    An embedded system could easily shave quite a bit of that down,
>    but even if it didn't we're talking about less than $1 _retail_
>    cost.
>    
>  > > less than $.50. Moore's law will make the cost of
>  > > crypto an utterly insignificant cost in the
>  > > future. Also: MEGACO and MGCP mandate the use of
>  > > IPsec, and the main feedback there was the worry
>  > 
>  > Megaco and MGCP are also almost exclusively run without 
> IPsec right now
>  > (Apparently, they aren't used all that much, but that's a separate
>  > problem). 
> 
>    The IETF isn't the protocol police, &tc. Are you
>    saying that MEGAGO/MGCP should just face reality
>    and put - oh say - digest authentication in too?
> 
>  > Plus, they are fixed-association devices across a single
>  > network hop, so none of the difficulties we're discussing 
> here apply.
> 
>    May I ask how you plan to do/scale cross realm Digest
>    since you're throwing the PKI scaling spectre around?
>  
>  > > Digest is worse than nothing at all (Basic at
>  > > least doesn't cop an attitude that it's anything
>  > > less than inadequate): as currently -- and likely
>  > > forever -- implemented does not provide basic
>  > > security features like replay protection,
>  > 
>  > You keep repeating this, but that still doesn't make it correct.
> 
>    \/\/hatever. Be my guest. Build insecure boxes for
>    specious reasons. Declare the problem intractable
>    and substitute non-scalable fake security instead.
>    Maybe we can have a great big group hug after we
>    properly fawn over the emperor's new cloths.
> 
> 		 Mike
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 29 16:04:57 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10053
	for <sip-archive@odin.ietf.org>; Mon, 29 Jan 2001 16:04:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7B1B74435C; Mon, 29 Jan 2001 15:05:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 641A844336
	for <sip@lists.bell-labs.com>; Mon, 29 Jan 2001 15:04:39 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA10898;
	Mon, 29 Jan 2001 16:07:22 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9K28FP>; Mon, 29 Jan 2001 16:00:58 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F309A8@DYN-TX-EXCH-001.dynamicsoft.com>
From: Ben Campbell <bcampbell@dynamicsoft.com>
To: "'Rick Dean'" <siplist@fdd.com>,
        "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
Subject: RE: [SIP] draft-ietf-sip-handoff-00pre8.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 29 Jan 2001 16:00:54 -0500

Sorry for the lateness of my comments. I just came back from back to back
vacation and flu.

I am concerned about the statement that a UA should automatically process a
HANDOFF without asking the user. This seems dangerous to me; I envision a
scenario where someone calls me, then transfers me to a billable service
without my consent. 

I did notice the section about being able to administratively block such
things at a proxy. I am still thinking about whether that is sufficient
protection, as it would require some level of administrative forethought. I
suspect we would find a lot of cases of closing the barn door after the
horses have left.

I realize you added this requirement because of timing issues, but it seems
to be a rather harsh presumption of decisions that at least sometimes should
be left to the user.

> -----Original Message-----
> From: Rick Dean [mailto:siplist@fdd.com]
> Sent: Wednesday, January 17, 2001 12:27 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] draft-ietf-sip-handoff-00pre8.txt
> 
> 
> 
> Dear SIP list,
> 
> Although we would like more time to 
> edit this poor draft, we feel a sneak
> peek is warranted due to its urgent nature
> with the upcomming meeting.
> 
> http://phonectl.sfour.com/draft-ietf-sip-handoff-00pre8.txt
> 
> Some significant differences from REFER are:
>   * narrower scope
>   * method completes without prompting
>   * referred-by like header generated by transferee
>   * location of headers for spawned invite
>   * error processing & final notification
> 
> Cheers,
> Rick
> rick_dean@3com.com
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 29 20:40:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13627
	for <sip-archive@odin.ietf.org>; Mon, 29 Jan 2001 20:40:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 75DC344337; Mon, 29 Jan 2001 19:41:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69])
	by lists.bell-labs.com (Postfix) with ESMTP id 261CE44336
	for <sip@lists.bell-labs.com>; Mon, 29 Jan 2001 19:40:52 -0500 (EST)
Received: from njb140r1.ems.att.com ([135.65.202.58])
	by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id f0U1eaj09172;
	Mon, 29 Jan 2001 20:40:37 -0500 (EST)
Received: from njb140bh2.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2)
	id UAA20446; Mon, 29 Jan 2001 20:39:30 -0500 (EST)
Received: by njb140bh2.ems.att.com with Internet Mail Service (5.5.2653.19)
	id <DHKS350T>; Mon, 29 Jan 2001 20:40:35 -0500
Message-ID: <E5B80B001D76D211879C00E02910776107D67CA1@njc240po05.mt.att.com>
From: "Roy, Radhika R, ALCOO" <rrroy@att.com>
To: Sean Olson <sean.olson@ericsson.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>, ??? <hkjung@contela.com>,
        Rick Dean <siplist@fdd.com>, Rohan Mahy <rohan@cisco.com>,
        sip@lists.bell-labs.com
Subject: RE: [SIP] draft-ietf-sip-handoff-00pre8.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 29 Jan 2001 20:40:29 -0500

TRANFER or similar term seems to be more acceptable to me/Radhika

-----Original Message-----
From: Sean Olson [mailto:sean.olson@ericsson.com]
Sent: Monday, January 29, 2001 2:35 PM
To: Roy, Radhika R, ALCOO
Cc: Patrice Calhoun; ???; Rick Dean; Rohan Mahy; sip@lists.bell-labs.com
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt


The name can be confusing, I agree. But as with all
specifications, you need to read them in the appropriate
context. I personally find HANDOFF completely apropos for
this usage because it is a SIP method and because the
introduction in the draft does a good job of establishing
the scope and meaning of the method. If HANDOFF is
taboo, how about "TRANSFER"? Nevermind the confusing
part about the transfer draft defining REFER and the handoff
draft defining REFER :)

my two cents
/sean

Roy, Radhika R, ALCOO wrote:

> Yes, as PatC pointed out, the term "HANDOFF" is creating a constant
> confusion.
> I, like many others, also point this to the WG for consideration.
> 
> Radhika R. Roy
> AT&T
> 
> -----Original Message-----
> From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com]
> Sent: Sunday, January 28, 2001 1:46 PM
> To: ???
> Cc: Rick Dean; Rohan Mahy; sip@lists.bell-labs.com
> Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
> 
> 
> Ahhh, I see that the misuse of terminology is biting this WG in the a..
> 
> This isn't a handoff as you, or I, or anyone else involved in mobility
> management understands it. It is rather a form of call transfer. You are
> correct that the handoff will occur at the GGSN/SGSN.
> 
> I have asked that the WG refrain from using the term handoff, or handover,
> given that the mobility folks will have serious issues with it (as they
have
> had with SIP Mobility, when it fact it is really portability). However,
the
> WG
> does not seem to be willing to listen to our requests :(
> 
> I suppose we will simply have to deal with the constant confusion we are
> creating in the marketplace by abusing terminology.
> 
> PatC
> 
>> Dear all. 
>> 
>> I am some curious about HANDOFF method. 
>> I think, HANDOFF method is required when SIP terminal moves from one
> 
> network
> 
>> to other network. 
>> 
>> In 3GPP TR23.821, the sentense,
>> " As a consequence, the behaviour of the multimedia call control server
>> (CSCF) can be the same whatever the access technology (radio or
> 
> wired-line).
> 
>> Multimedia call control/mobility management shall not be aware of the
> 
> access
> 
>> technology: the multimedia Call Control (CSCF) does not handle notions
> 
> such
> 
>> as Hand-Over, RA, "
>> 
>> It means that handoff is the problem of GGSN and SGSN not CSCF which
> 
> support
> 
>> SIP protocol. It is not the business of CSCF. 
>> 
>> Therefore I think HANDOFF method is not required at least 3GPP. 
>> 
>> What do you think about this? 
>> 
> 
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 29 20:52:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13781
	for <sip-archive@odin.ietf.org>; Mon, 29 Jan 2001 20:52:56 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 36DE544338; Mon, 29 Jan 2001 19:53:07 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from channeli.net (unknown [210.112.223.112])
	by lists.bell-labs.com (Postfix) with ESMTP id F19B544336
	for <sip@lists.bell-labs.com>; Mon, 29 Jan 2001 19:51:37 -0500 (EST)
Received: (from root@localhost)
	by channeli.net (8.9.3+Sun/8.9.3) id KAA02167
	for sip@lists.bell-labs.com.outgoing; Tue, 30 Jan 2001 10:51:22 +0900 (KST)
Received: from arnold ([210.121.191.94])
	by channeli.net (8.9.3+Sun/8.9.3) with SMTP id KAA02098
	for <sip@lists.bell-labs.com>; Tue, 30 Jan 2001 10:51:16 +0900 (KST)
From: =?ks_c_5601-1987?B?wMzI8byu?= <hee7816@channeli.net>
To: <sip@lists.bell-labs.com>
Message-ID: <GDEILEINIBOHMBNJODGGAEFNCBAA.hee7816@channeli.net>
MIME-Version: 1.0
Content-Type: multipart/related;
	boundary="----=_NextPart_000_0009_01C08AAB.756B7070"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Subject: [SIP] Are there a few proxys in the same domain? In that case.......
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 30 Jan 2001 10:57:37 +0900

This is a multi-part message in MIME format.

------=_NextPart_000_0009_01C08AAB.756B7070
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_000A_01C08AAB.756CF710"


------=_NextPart_001_000A_01C08AAB.756CF710
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

DQoNCg0KSW4gdGhhdCBjYXNlLA0KImRyYWdvbiIgcmVnaXN0ZXJlZCBhdCAiYmJiLmNvbSIgZG9t
YWluLiANClNvIGFybm9sZCBzZW5kcyBhIHJlcXVlc3QoSU5WSVRFKSB0byBwcm94eSAxIHdpdGgg
cmVxdWVzdCBVUkkgd291bGQgYmUgInNpcDpkcmFnb25AYmJiLmNvbSIuDQoNCkhvdyBkb2VzIHRo
ZSBwcm94eSAxIHNlYXJjaCB0aGUgbmV4dCBwcm94eSBzZXJ2ZXIgaW4gdGhlbShwcm94eTIscHJv
eHkzLHByb3h5NCkgPw0KDQoNCg0KDQo=

------=_NextPart_001_000A_01C08AAB.756CF710
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: base64

PGltZyBzcmM9Imh0dHA6Ly93ZWJtYWlsLmNoYW5uZWxpLm5ldC93ZWJtYWlsL2J1dHRvbi5w
aHAzP2lkPWR1aGV0Zm9sbmFwbHZ3enZqc20mdXNlcj1oZWU3ODE2IiB3aWR0aD0iMSIgaGVp
Z2h0PSIxIj4KPCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBU
cmFuc2l0aW9uYWwvL0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2
PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA1LjAwLjMxMDMuMTAwMCIg
bmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWPjxJTUcgYWxpZ249YmFzZWxp
bmUgYWx0PSIiIGJvcmRlcj0wIGhzcGFjZT0wIA0Kc3JjPSJjaWQ6NjQ4MTAyMDEzQDI5MDEy
MDAxLTAyNGQiPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+
DQo8RElWPjxGT05UIHNpemU9Mj5JbiB0aGF0IGNhc2UsPC9GT05UPjwvRElWPg0KPERJVj48
Rk9OVCBzaXplPTI+ImRyYWdvbiIgcmVnaXN0ZXJlZCBhdCAiYmJiLmNvbSIgZG9tYWluLiA8
L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5TbyBhcm5vbGQgc2VuZHMgYSByZXF1
ZXN0KElOVklURSkgdG8gcHJveHkgMSB3aXRoIHJlcXVlc3QgVVJJIA0Kd291bGQgYmUgIjxB
IA0KaHJlZj0ibWFpbHRvOnNpcDpkcmFnb25AYmJiLmNvbSI+c2lwOmRyYWdvbkBiYmIuY29t
PC9BPiIuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6
ZT0yPkhvdyBkb2VzIHRoZSBwcm94eSAxIHNlYXJjaCB0aGUgbmV4dCBwcm94eSBzZXJ2ZXIg
aW4gDQp0aGVtKHByb3h5Mixwcm94eTMscHJveHk0KSA/PC9GT05UPjwvRElWPg0KPERJVj4m
bmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ
Vj4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0KPGJyPjxicj4KLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+Crj4uLu4rrTCIMDOxc2z3cOks84sPGJyPgrDpLPO
vsbAzCA8QSBocmVmPSJodHRwOi8vd3d3LmNoYW5uZWxpLm5ldCI+aHR0cDovL3d3dy5jaGFu
bmVsaS5uZXQ8L0E+PGJyPgo=

------=_NextPart_001_000A_01C08AAB.756CF710--

------=_NextPart_000_0009_01C08AAB.756B7070
Content-Type: image/jpeg;
	name="quest_graphic.jpg"
Content-Transfer-Encoding: base64
Content-ID: <648102013@29012001-024d>
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAgEASABIAAD/7Qj6UGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAAR/+0AAIA
AgBH/7QAAgACOEJJTQQNAAAAAAAEAAAAeDhCSU0D8wAAAAAACAAAAAAAAAAAOEJJTQQKAAAAAAAB
AAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP0AAAAAAASADUAAAABAC0AAAAGAAAAAAABOEJJ
TQP3AAAAAAAcAAD/////////////////////////////A+gAADhCSU0EAAAAAAAAAgABOEJJTQQC
AAAAAAAEAAAAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBBQAAAAAAAQAAAACOEJJ
TQQMAAAAAAfVAAAAAQAAAHAAAAA0AAABUAAAREAAAAe5ABgAAf/Y/+AAEEpGSUYAAQIBAEgASAAA
/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwR
DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwR
EQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgANABwAwEiAAIRAQMRAf/d
AAQAB//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQAC
AwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIz
NHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV
5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEi
EwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N1
4/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A9EwM
DCtwqLbaK32Pra573NBc5xG5znOd7nOc5H/ZfTv+41X+YEPCtNXS8Vwbu/RtkCSY2zo1jXvd/mov
2t2wP9MwXBv0LZk/yfR3bf5f0ElLfsvp3/car/MCX7L6d/3Gq/zAotzy4e2t3eNzLWD2+LrKWtZ/
aVj1XO/mm7h+84wD/V+k5ySkP7L6d/3Gq/zAl+y+nf8Acar/ADAjbrhqWAjwa7X/AKTW/wDVKTHt
eJb8CDoQfNJTX/ZfTv8AuNV/mBL9l9O/7jVf5gVpQtsFVZeRMcDxPgkprP6f0tkbseoTwNgJPwbC
j9gwDxgsI8drB+Uqw2lx91jjvPO3T8fpJy91P0yXtP0TpM/udvpfmJKa4wemTD8WthOg3MbH+cJY
qd2LhVuIGMx2hcT7xHue3itjme3b+9/mLUNTnj3vMn81vA/8n/bVf7Kz1RXbDgQTW4sYToS7Zqz8
3d7UlNG/HwarLGDGr9hbtn1NQefot/6jelfi4rKrX10NqfUWFjml8gzz7wz6MfmrTdhVOJc6HOdG
4ljCTHE+xV8/GZXh3OaY0BMNaJgwN21oSU//0PSunMY/puKHtDgK2ESJ12o/oU/uN+4IPS/+Tsb/
AIpn5FaSUgsopc9texsGXO0GoEe3/OcpvvoY7Y+xrXbd20kA7R+d/VQ7MihmZVSbG+u9jiKpG/ZL
Qbdn0vTbZsr3/v21oxYxxlzQTESR2SUj+14m0O9avadAdwgk/NSs9r22DuQ13mD9H/NcpCuscNA+
ACHkN9UCkOLC7Uubo5oBncJn872pKTIN4c5zWt1IDnNH8ppbtQf2e7/uXkf5zf8A0mo0YRw7rck5
N+QLnNLmXODm1tDRWfQa1jPTa5zW22pKSjH9Qbm5Fv0y+JAif8ERt+gz91M+pw9rXvtc1wsO4gxt
4rH0fpomQ2sDdt9503ASdBuP0fc72t+ggMtwoAFVuo3BxptB/wA70/a5JSRmLS4B7bLSNxcP0r+S
fou930f+DeomtrA4sLnNq9xLnFx3S121peXfmsU6m1WySCdAZcC1xBlobY121zvo/ntU3geypojU
HTgBp3f+YpKSqr1P+gXfAflCtKr1P+gXfAflCSn/0fS+l/8AJ2N/xTPyKWVlegGsrZ6uRbIppBiY
+k+x8O9Kiuf0tv8A236t9lNNtfAcRh44Lntb6FcbWyJg7tdjlI25msARJ2yX8a7d36v/AFElJMbB
ZU5110XZdo23XloBLf8AQ1t93pYzP8HRu/4Sz1b7LrrDbbWfQIc391/P+eqrLc3h4HHILuY/d+zf
9/RK32EfpXOa6dAwFwj4upakpN+nOkNZ5yXfhDFJjAyeS48uPJTUlxqYXyXFokkQZjuPappKUkkk
kpA+t7QAzVoMtHdpHhxuYl9p7OqsB7w0kf5yOh3FwrJbIMjUCTEjd+9+akpgx1hJc1svdy4y1oA4
b7ve7/NUcjFssYHVWmvJYdzLNS0n/R21SPUod/o/+uVv9f8ATKNr7hHouL+ZDwW/1Y20PQzbnSID
YnUEu4n/AIj6SSk+Jl+uHMe30siqBdSTO0n6L2O9vqU2R+it/wDPd1dtVcep/wBAu+A/KFWfjmzK
ozHs/WaGvY2wOsG1lm3169raWsuY/wBKp2278+v1FPPcTi2gOe5uwzubAnczb+Y1JT//0u8xP239
lq+zeh6G0ej6k79n+D9TZ7PU2fT2o3/ZH/3V/wCmvmhJJT9L/wDZH/3V/wCml/2R/wDdX/pr5oSS
U/S//ZH/AN1f+ml/2R/91f8Apr5oSSU/S/8A2R/91f8Appf9kf8A3V/6a+aEklP0v/2R/wDdX/pp
f9kf/dX/AKa+aEklP0v/ANkf/dX/AKaX/ZH/AN1f+mvmhJJT9L/9kf8A3V/6aDl/tr0HfavQ9CW+
r6c79u5u/wBPf7N+1fNySSn/2QA4QklNBAYAAAAAAAcAAQAAAAEBAP/iAaBJQ0NfUFJPRklMRQAB
AQAAAZBBREJFAhAAAG1udHJHUkFZWFlaIAfRAAEAHQAWABIAIGFjc3BNU0ZUAAAAAG5vbmUAAAAA
AAAAAAAAAAAAAAAAAAD21gABAAAAANMtQURCRQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAABWNwcnQAAADAAAAAJGRlc2MAAADkAAAAcXd0cHQAAAFYAAAAFGJr
cHQAAAFsAAAAFGtUUkMAAAGAAAAADnRleHQAAAAAKGMpIDIwMDEgQWRvYmUgU3lzdGVtcyBJbmMu
AGRlc2MAAAAAAAAAFkdyYXlzY2FsZSAtIEdhbW1hIDIuMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVogAAAAAAAAAAAAAAAAAAAAAGN1cnYAAAAAAAAAAQIz
AAD/7gAOQWRvYmUAZIAAAAAA/9sAQwAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwM
DBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AACwgBnwN+AQERAP/dAAQAcP/EAKIAAAEF
AQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMi
cYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj
80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3/9oACAEBAAA/AO9+tH1o
6f8AVfp9efn13W1W3ChraA1ztzm2WgkW2Ut2baXfnLl//Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cX
P/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3q
S/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A
3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/
96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr
/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp
/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev
6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7b
p/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8A
Hr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/
APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv
/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBx
c/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDe
pL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9
xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8A
epL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+q
v/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtu
n/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+
qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A
7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x
6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//
ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/
AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cX
P/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3q
S/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A
3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/
96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr
/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp
/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev
6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7b
p/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8A
Hr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/
APtun/3qS/8AHr+qv/cXP/7bp/8AepdL/wA7+jf81/8AnTus/Z3p742H1N2/7P6Hp/R9X7T+r/T9
Df8A4b0P0q//0NX/AB1/+JXF/wDD9f8A55yl6Akkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkksev6wZF5tOL0jNyaqrraPWY7Ea1
zqLH4txY2/Opu2etS/8AnKmKX7Z6j/5RZ/8An4P/AMkkv2z1H/yiz/8APwf/AJJJftnqP/lFn/5+
D/8AJJL9s9R/8os//Pwf/kkl+2eo/wDlFn/5+D/8kkv2z1H/AMos/wDz8H/5JJftnqP/AJRZ/wDn
4P8A8kkv2z1H/wAos/8Az8H/AOSSX7Z6j/5RZ/8An4P/AMkkv2z1H/yiz/8APwf/AJJJftnqP/lF
n/5+D/8AJJL9s9R/8os//Pwf/kkl+2eo/wDlFn/5+D/8kkv2z1H/AMos/wDz8H/5JJftnqP/AJRZ
/wDn4P8A8kkv2z1H/wAos/8Az8H/AOSSX7Z6j/5RZ/8An4P/AMkkv2z1H/yiz/8APwf/AJJJftnq
P/lFn/5+D/8AJJCy/rHlYWLdmZPRM+vHxq3W3P3YR2sYDZY7azqLnu2sb+ai/Wz/AMSvWf8Awhlf
+ebFwH/5if8AX/ywX//R1f8AHX/4lcX/AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSyfq1/wAnXf8Ah/qP/t9m
LWSSSSSSSSSSSSSSSSSSWT9bP/Er1n/whlf+ebEvrZ/4les/+EMr/wA82LgP/wAxP+v/AJYL/9LV
/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ
JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJLJ+rX/ACdd/wCH+o/+32YtZVMbq3Ssu842LmY9+QK2
3Gmq1j3+m4MfXd6bHOf6T2W1OZZ9D9LWhWfWHoFbDZZ1PEYxvp7nOvrAHrNN+NLi/wD7UUtddR/p
av0latV5eLb6XpXV2faKzdRtcD6lY2TdVtP6Sr9NT+kZ7P0tf76jX1Hp9tXrVZNL6t1bPUbY0t3X
Ct2OzeHbd+Q3Ix/Q/wBL69Pp/wA6s+3rXUKbBfbgtr6acluILXWubk7n3jp1V32F2P6P2ezKeyyu
z7f78H9a/nP1ZaV2R6VlFfp2WfaLDXuY2W1wyy/1L3f4Or9D6O//AE9tNf56nddVRU+657aqqml9
ljyGta1o3Pe97va1jWqli9aws7Kqq6ffj5mPZXc5+RRfW/a+k4zfR9Ktzn2bmZe+yxv9H/Rer/Sq
UXG6t0rLvONi5mPfkCttxpqtY9/puDH13emxzn+k9ltTmWfQ/S1qHR+pO6ng/a30OxXetfS6h7mu
c00XW4h3uq3Vb3ehu/RvsZ/wtv8AOIWT1/p+F1C/Fz7qcOqmnHtbkX2tra52Q7MYKB6uxu9jenus
+n7/APrSWT1/p+F1C/Fz7qcOqmnHtbkX2tra52Q7MYKB6uxu9jenus+n7/8ArSWT1/p+F1C/Fz7q
cOqmnHtbkX2tra52Q7MYKB6uxu9jenus+n7/APrS01UwerdK6lv/AGdmY+Z6Uep9ntZbt3Ts3+k5
+zfsftUMbrnRcuq+7F6hjZFWK3fkWVXVvbW2HO33vY9zamba3/zn7ijX9YegW+l6XU8Sz7RYaaNt
9Z9SwbJpq2v/AElv6an9Gz3/AKWv99aCyfrZ/wCJXrP/AIQyv/PNiX1s/wDEr1n/AMIZX/nmxcB/
+Yn/AF/8sF//09X/AB1/+JXF/wDD9f8A55yl6Akkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkksn6tf8AJ13/AIf6j/7fZi1lx/1W
x8y/pH1ZrbgfZMfp9deW/Ia6s02izEyKP0La3DK+13W57cjJ9fEpq9T7V+s3/obMmx0zped0fC6D
bXgOtdg9OfiZWJjGlr233/Yr7bv092NivZ62FkfaLGZHqPuuZZ+l/S2Vyr6L1K3Gx6A37Fa+zqGU
/MDpspGVe/Jp6a/7NdS932hmU37a6jIfVW/p/wCqX15n7O6nigxcZ13UW9LqrpxqrXYXUuo4dT2v
fhW4tePs6fuob6FLLX4nSPsTHV/rOLR1qyp9f6or9VvUrerm7O6VkvbTc6rCe1+Kceqsk0/b4dmN
yrMjIpO+yz7L62LjWfYsaj+mXZ+xd9q9Sj0PT9L1D9q3zu9PZZt9Db7fV+0/Z/5z2eh63+E2Kv1n
GdldOsrZW66xrq7a2se2t4fVYzIrsofc19H2il9XrY9WT+q33V105X6vZasXpHT+tH6yV9SzKbvs
zMK7H9fM+yDL3utxbmU2fsn9XfhbK7H4n+Grv+3+t7LcZV/qtj5l/SPqzW3A+yY/T668t+Q11Zpt
FmJkUfoW1uGV9rutz25GT6+JTV6n2r9Zv/Q2ZO106nP6f0jLjH9bLbkZ+RRjb2t9T1cnKysRnre6
ur7RXbV7n/zW/wDSKvk1Z2J9ZL+q1dMdnVWYWPjMtpfSL2ubbmXXVsbl2Yzfs7m2Y7r/ANYZ+k+z
enTkfpX4tLpnTOp9Eysa13Tv2h6HSMHpxvxn0iwWUHJdkspGa/E/VH7qH2v9ap+/7L+r3fpvsi6Z
0zqfRMrGtd079oeh0jB6cb8Z9IsFlByXZLKRmvxP1R+6h9r/AFqn7/sv6vd+m+yW29J6kfqrZ9W3
Mra9vSK8OvL3zW+91NuJczZs9ZlVHp0W+t6f6VmR/N/olLPqzuudPz8U9MdgW3YWRjU5GY+kuDsh
oY2uv7BZnu+zucz1Mve+r+axvTpyf+09XrGJ1XrVWZYzp92I5vSs/CqqyH0brbcsYxoFX2XJyqms
Z9jd6rsiyj+dp/nP0vpWOt9Lz8r9v+hVv+39IrxMX3NG+5v7T3Ve5zdn9Lx/fZ+j/Sf110CyfrZ/
4les/wDhDK/882JfWz/xK9Z/8IZX/nmxcB/+Yn/X/wAsF//U1f8AHX/4lcX/AMP1/wDnnKXoCSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSyf8AnT0J
/wDRcr7fH0/sFdmbs/d9f9m15Xob/wDBet6fq/pPT/m7Ev2r1bI0wek2AH3NuzrWY1bmfmljKP2h
n12v9rvQy+n43s9T1/Ru/QJf9lV//cDp23/js7fP/uE+z+n/AOhPq7/8D6X6VfYPrBd7cnqtdLBq
HYOK2qyf3Xv6hd1en0v5LcZlu/0/0/067V+xuo/+Xuf/AJmD/wDI1L9jdR/8vc//ADMH/wCRqX2b
61f+WOB/7A3f/JVL1/rUz2fYsC7bp6v2u6rfH+E+z/s/K9Df9L0ftWT6X0PXu/nEv2/6X9O6bn4c
/wA3+g+1bo+l/wAjP6n6Oz2/0n0PU/wPqfpfTsYXW+kZ9pow8ym7JY3dZjB4F7ACGv8AtGK6MjHf
W93p213VVvqs/R2e9Xkkkkklk/Vr/k67/wAP9R/9vsxayqY3VulZd5xsXMx78gVtuNNVrHv9NwY+
u702Oc/0nstqcyz6H6WtCs+sPQK2GyzqeIxjfT3OdfWAPWab8aXF/wD2opa66j/S1fpK1ary8W30
vSurs+0Vm6ja4H1Kxsm6raf0lX6an9Iz2fpa/wB9Rr6j0+2r1qsml9W6tnqNsaW7rhW7HZvDtu/I
bkY/of6X16fT/nVn29a6hTYL7cFtfTTktxBa61zcnc+8dOqu+wux/R+z2ZT2WV2fb/fg/rX85+rL
SuyPSsor9Oyz7RYa9zGy2uGWX+pe7/B1fofR3/6e2mv89Tuuqoqfdc9tVVTS+yx5DWta0bnve93t
axrVSxetYWdlVVdPvx8zHsruc/IovrftfScZvo+lW5z7NzMvfZY3+j/ovV/pVKTuvdKLL/suRXnZ
GPjnKOHiPZbe+va26t1OOx+9/rssq9D8y31qv9IoYnUuoftBmB1LFpx7b6bL6HY97r2ltLqarxab
sbBdU/dmUelsbd6n6b+a2fpVk9f6fhdQvxc+6nDqppx7W5F9ra2udkOzGCgersbvY3p7rPp+/wD6
0lk9f6fhdQvxc+6nDqppx7W5F9ra2udkOzGCgersbvY3p7rPp+//AK0lk9f6fhdQvxc+6nDqppx7
W5F9ra2udkOzGCgersbvY3p7rPp+/wD60tNVMHq3Supb/wBnZmPmelHqfZ7WW7d07N/pOfs37H7V
DG650XLqvuxeoY2RVit35FlV1b21thzt972Pc2pm2t/85+4o1/WHoFvpel1PEs+0WGmjbfWfUsGy
aatr/wBJb+mp/Rs9/wClr/fWgsn62f8AiV6z/wCEMr/zzYl9bP8AxK9Z/wDCGV/55sXAf/mJ/wBf
/LBf/9XV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ
JJJJJJJJJJJJJJJJJJJJJJJKjm9YwsO0YxLr817d9eFQPUvc0ksZYa2/zGO61vpfbMp1GFVZ/P5N
Sr+n9YM73Pur6Tju4qqa2/LA+mx5ybt2Bj2/4O/G+xdSq/nPQzrPVrtpX/Njo1vuz6P2padTZnk5
MOP84+inI342F6zv52vBoxaP5v8ARenVVs1kkkkkkkklXzendP6hUKc/Gpy6mu3trvrbY0OALQ8M
ta5u/a5yo/sH7Nr0rMyMCNRRu9fGO3+Zq+yZnrfZcSv6H2fpdvTf0P6P1P0eP6K/aHVcDTqmN9qp
H/a3AY98f8f0ucjNq9zmVVfY7Oqb/wBJkZH2KpaGLl4ubQ3Jw7q8nHsnZdU4PY6CWO22VlzHbXt2
oySSyfq1/wAnXf8Ah/qP/t9mLWXH/VbHzL+kfVmtuB9kx+n115b8hrqzTaLMTIo/QtrcMr7Xdbnt
yMn18Smr1PtX6zf+hsybHTOl53R8LoNteA612D05+JlYmMaWvbff9ivtu/T3Y2K9nrYWR9osZkeo
+65ln6X9LZXKvovUrcbHoDfsVr7OoZT8wOmykZV78mnpr/s11L3faGZTftrqMh9Vb+n/AKpfXmfs
7qeKDFxnXdRb0uqunGqtdhdS6jh1Pa9+Fbi14+zp+6hvoUstfidI+xMdX+s4tHWrKn1/qitZuHnZ
mdUbOltZ1CjJrNXWmeiGNxK8j7T9nbab3dUa+/p3qYeRV9l9C3Kvv/7RW+st277V6lHoen6XqH7V
vnd6eyzb6G32+r9p+z/zns9D1v8ACbFX6zjOyunWVsrddY11dtbWPbW8PqsZkV2UPua+j7RS+r1s
erJ/Vb7q66cr9XstWL0jp/Wj9ZK+pZlN32ZmFdj+vmfZBl73W4tzKbP2T+rvwtldj8T/AA1d/wBv
9b2W4ypdBr6m76vfV/7J0rb+zMcZrC22llOS5+Fk0100vDvtFWXlZGdXbkvycOqiqz7V+s5H6KzJ
1+nW9Sqqy739KyX9SfS6112Q/FrbfZWD9nwKPs2ZnOw8fc97cat/6Gn9NfkX3Zd19+SsmrOxPrJf
1Wrpjs6qzCx8ZltL6Re1zbcy66tjcuzGb9nc2zHdf+sM/SfZvTpyP0r8Wl0zpnU+iZWNa7p37Q9D
pGD0434z6RYLKDkuyWUjNfifqj91D7X+tU/f9l/V7v032RdM6Z1PomVjWu6d+0PQ6Rg9ON+M+kWC
yg5LsllIzX4n6o/dQ+1/rVP3/Zf1e79N9ktt6T1I/VWz6tuZW17ekV4deXvmt97qbcS5mzZ6zKqP
Tot9b0/0rMj+b/RKWfVndc6fn4p6Y7AtuwsjGpyMx9JcHZDQxtdf2CzPd9nc5nqZe99X81jenTk/
9p6vWMTqvWqsyxnT7sRzelZ+FVVkPo3W25YxjQKvsuTlVNYz7G71XZFlH87T/OfpfSsdb6Xn5X7f
9Crf9v6RXiYvuaN9zf2nuq9zm7P6Xj++z9H+k/rroFk/Wz/xK9Z/8IZX/nmxL62f+JXrP/hDK/8A
PNi4D/8AMT/r/wCWC//W1f8AHX/4lcX/AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSo5vVasW0Y1dN2ZmObvbi47Q520kgPtttdTiYrH7Lf
S+2ZOP8AaPRuqxvWuZ6ar/Y+uZumdlV4WO76WNghxsj6Lqn9Uv2PdVazc79U6f0/Mpf6foZn6H1b
72F0/CwKjVh0tpa92+wjVz3kBr78i1025GRZt/S5Fz7Lrf8ACWKwkkkkkkkkkkkkks/K6Ji3XuzM
d9mBnPjfl4pDHvgCtv2muxtuLm7Kv0VP27Hyfs3/AGm9Gz3oP7Q6rgadUxvtVI/7W4DHvj/j+lzk
ZtXucyqr7HZ1Tf8ApMjI+xVLTpuqvqZdS9ttVrQ+uxhDmua4bmPY9vtcxzVNZP1a/wCTrv8Aw/1H
/wBvsxayzOn/AFj6P1J1Iw7nWNyG7se01Wsqs9vqOqoyra2Y92RWxtnq41dv2in0cj1av1a/0xU/
W3oV9TLsa27JrtaH1GjGyLd7SPc+ltNFjrWUOLasz0/6FkPrxcv0MixlSu4/VMDJfRXTbufk12W1
N2uB20OroyRY17W+jbj3X103UXenfXb+j9P9FahY/X+k5OL9sov34/qUVb9jx78sY9mG3a5gf+mZ
n4n/ABfq/pdnp2qpm9byq/rFgdNxWVuxH2Opz7XAlzbH4+TnYtOO9jvTbbXXhermV3M3+hl4Hp/0
hat1l7LKG1U+qyywtvfuDfSZsssF21387uuZTj+mz/T+r/gksrKow6HZGQ7ZUyJMFxJcQyuuutgd
ZbbbY5tdNNbfVut/RVfpFn4vXsbN6rVhY79s4911uPkU30ZPsfjV03Mqyqqf1T9Nex1j/wCeu/o3
9Hy/TjV9aOnZuObOlF2bbbS6zCaWWU1ZDww3NxaM/IqbifaPa71afU9bG9LI9er9VyPTh0vquVb1
Wzp1uXidS9Oux19mEw1/ZrKn1VDFzGOyuofpcr1bvR3vxn/qOR7Lv8BPJ+sNOH1q/p+TuLWY2PkU
soptvvcbbMyrIeacRl9v2er7NjfpfR2VWX/pbf09Kg/6zYdXVbMV7/Wx3YmNl4pxa7MmywXPy2W3
Nrwm5D34jGY+L+nbV6TH3++39PQk/wCs2HV1WzFe/wBbHdiY2XinFrsybLBc/LZbc2vCbkPfiMZj
4v6dtXpMff77f09C1fteL9l+2+tX9k9P1vtG4en6cep63qz6fpen7/U+hsVXH690y/1JfZjejW65
/wBrpuxP0bP565v2+rG9Sqjcz17K/ZR6lXrfztag36xdKNWRa991DcWl+RaMjHvod6VY3X3VVZVN
NuQyn2+r9nZb6fqU/wCmqUP+c/SB9N2RVGtnq4uTX6bP+5GV6uOz7JifT/XMr0cX9Dk/pv1XI9LW
WT9bP/Er1n/whlf+ebEvrZ/4les/+EMr/wA82LgP/wAxP+v/AJYL/9fV/wAdf/iVxf8Aw/X/AOec
pegJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJLJ+339W9
vRcituGNLephoua4nR1PTfd6NttX+EzbPtGHj3/q32bOt+2VYV7C6fhYFRqw6W0te7fYRq57yA19
+Ra6bcjIs2/pci59l1v+EsVhJJJJJJJJJJJJJJJJJZl3RW1Wvy+kvb0/LscX2+1z8e1zzN1mVgV2
49VuRZ9L7ZW+nN/R078mzG9TGtLhdUqyLTh37cbqVbd12GXAu2ghv2nH+g7Jwnud+iym1/8AA3sx
8uu/Fpr/AFa/5Ou/8P8AUf8A2+zFrLl/q703rT+nfV9mfXTRV0umq5rgbBe5xxLMIYmRhW17cZ9D
cx3q3fbLvUsxv6LR9o9PFsYvR+q9PxejPxm4+Tl9MwDgXVWWvqrdvGH6l9eQzHybP0dnT9rKnYv6
Rl2/1KvS9O1f83L8jDpwcx9Yx3WZmXk+mA57b8qyy6qmh+RU+u3EprzsyrI9Smr7dspqyMf7DlZ2
DaGnAzcnqzacjSo/Zs3rDa6rG0OzsdlYp+x5ORssvqvsZhX/AKtY9mJ+xPs+Wz1Op3I1v1YyW9Tx
c3H6jkelXnvzsimwUEe+nIo2V2fZPtNntuqw2faMn9D079FRYyyjF9PaurvfZQ6q70mV2F17Nod6
rNllYp3O/mttz6cj1Gf6D0v8KhdUxX5eBbRW2t73bXNbaXNaSxzbGxdQRdjW+z9BmU/pcK/08quq
30fSWP0jofVsfrVfUMp7a8WvGuobiHKvznNstsxbftDc3Prqv2XMxfSfi/zOP6FdtO/7XkenV6R0
n6w5HQ+i49zqcB3TsZllGSA917bXYd2BVVkdNyK21VPxPtu+1/2y317MT+jY/wBp/VdI4vX78o9R
sqxMbLxsTIx8Ktt1mRW+zIOPax+U842DZTVTZg1+2plz7WXP/mvS/SzycTrVPWr+pYDMa+q/Gx8d
1F9llLt1NmZcbRfVTltaxrctrPS9D9N/psf7P+tVMLovWuj21HA+zZlVXTsPp7mXvsx3OdiHKnJF
lVWa2tm3Ib+r+lb6m/8ApFP2f9bWF0XrXR7ajgfZsyqrp2H09zL32Y7nOxDlTkiyqrNbWzbkN/V/
St9Tf/SKfs/63Yb0LK/YFn1dffX9k/ZleBVkhh9T1PTtxci+ynf6fpen9lspqbbv3+vvs/m1PJxO
tdW6fnYGezGwasvGtx2uossynbrm+kLSbaenNrZQ3d+i22/aN/8APY3o/p6nUukda6xVlnKrxsS1
3TszAx2VXWXtc7MFP6W+x+LiOoZQ7EZ/N1ZHq+t/g/R/TWOrdEys39tek+tv7T6YzBo3EiLG/tCX
27Wu21fr9P0N7/5z9GttZP1s/wDEr1n/AMIZX/nmxL62f+JXrP8A4Qyv/PNi4D/8xP8Ar/5YL//Q
1f8AHX/4lcX/AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSShddVRU+657aqqml9ljyGta1o3Pe97va1jWrM239a9uRRZi9L/OouAbZlA6t9aoOc
/H6fs/nMXI9LMy3/AKtm4+Ni1X4/UNZJZ+V9YegYV7sbM6niY2RXG+m2+tj2yA9u6ux7Xt3MduQf
+dn1V/8ALnA/9iqf/Sit4PVuldS3/s7Mx8z0o9T7Pay3bunZv9Jz9m/Y/araSSSSSSSSSSSqZ3Vu
ldN2ftHMx8P1Z9P7Rayrdtjfs9VzN+zezcqn/Oz6q/8Alzgf+xVP/pRWMLrnReoWmnA6hjZdrW73
V0XV2ODQQ0vLKnuds3Oaryr5uFVm1Bjy6uyt3qUX1wLKrAC1t1LnBzd+1z2Oa9j6bqX2Y+RXdj3W
1Pz/AKqC0dJeLnNfaM3qAsexpY0u+25e9zK3PtdWxzvzPVs/4xbCSSSSSSSSSSSSSSSSSSyfrZ/4
les/+EMr/wA82JfWz/xK9Z/8IZX/AJ5sXAf/AJif9f8AywX/0dX/AB1/+JXF/wDD9f8A55yl6Akk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkg5WVRh0OyMh2ypkS
YLiS4hldddbA6y222xza6aa2+rdb+iq/SKlTiZudazJ6ntroY4W43TmidjwZqsz7m2WVZeRTtbbT
VS1mLiZH/c+7Gw8+uxndUwOn7BlW7bbp9GhjXW3WbY9T7PiUNtycj0mu32+jU/0q/wBJZ+jVT1vr
Jl60UY/S6jq1+WTk3ae0124WFZRjVbne9l1fVsr9H/gPUt/V1/zdxb/+VL8jq3bZlvHolv5rLen4
jMXpt+x/6VlmRh23+p/hf0NHpaGLiYuFQ3Gw6a8bHrnZTU0MY2SXu211hrG7nu3IyqZ3SeldS2ft
HDx8z0p9P7RUy3bujfs9Vr9m/Yzcqn7Fysb3dL6jkUxr6GWTm0ucfa59py3/ALS+h9CvH6njUMs/
Sel/P+uv2l1XC/5UwvUpGn2vA338e31L+n+n9tp9Z2z0qcP9rej+k+0X+lT9os0MXLxc2huTh3V5
OPZOy6pwex0EsdtsrLmO2vbtRkkkkklC66qip91z21VVNL7LHkNa1rRue973e1rGtWZ+2MrM/wCR
cP7XUNfteQ842M4f91rfRycnK3tdXbTkUYf7Ovp/ms/1P0SX7J6llf8AKfU7HM4dj4LfsdbgPc1z
7RZk9TZbv/Oxup49T2enV6H8/wCvbwek9K6bv/Z2Hj4fqx6n2eplW7bOzf6TWb9m9+1W1XzendP6
hUKc/Gpy6mu3trvrbY0OALQ8Mta5u/a5yo/sH7Nr0rMyMCNRRu9fGO3+Zq+yZnrfZcSv6H2fpdvT
f0P6P1P0eP6K/aXVcL/lTC9Skafa8Dffx7fUv6f6f22n1nbPSpw/2t6P6T7Rf6VP2izN+r31i6bX
gWhoyb2uzc97LcfEysipzX5mVZW+nKxMe7HuY5j/APBWrQt+tfSaWh9rM2tpc1gc7p+a0bnuFVTJ
difTsteyuv8Afepf85enf6HP/wDcdnf+8aX/ADl6d/oc/wD9x2d/7xpf85enf6HP/wDcdnf+8aX/
ADl6d/oc/wD9x2d/7xpf85enf6HP/wDcdnf+8aX/ADl6d/oc/wD9x2d/7xpf85enf6HP/wDcdnf+
8aX/ADl6d/oc/wD9x2d/7xpf85enf6HP/wDcdnf+8aX/ADl6d/oc/wD9x2d/7xpf85enf6HP/wDc
dnf+8aX/ADl6d/oc/wD9x2d/7xpf85enf6HP/wDcdnf+8aX/ADl6d/oc/wD9x2d/7xpf85enf6HP
/wDcdnf+8aX/ADl6d/oc/wD9x2d/7xpf85enf6HP/wDcdnf+8aX/ADl6d/oc/wD9x2d/7xrP+sPW
8XN6B1PDxsfPsyMnEvqpZ+z80bnvrfXW3c/Eaxu57vzlofWz/wASvWf/AAhlf+ebFwH/AOYn/X/y
wX//0tX/AB1/+JXF/wDD9f8A55yl6Akkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkksnA/ytfj9adphtrcemVHUubcG/5Suaf5q22n9HhV/wA/j4eRk/af0udbh4Rs
rMyrr3YPSzX9oqg5OTa02U0SBYyp1VdlD8jLuY5rvs7L6vQx3/a8iz34dGcXB6Zi4O99Td+TfBys
t4Buuc2dr8i1rWb9m93pV/zGNX+gxaqcfZUraSSSSSSz8rpU3uzumurwuo2QLbzXvZc0AMazOpY/
Hfk+kwfq1nr1343+Dt+zW5WNklwc77TvpuZ9nzceBkY5O7bun07arIZ6+Jfsf9nyNnv/AElVtdGX
Rk41FtJJJBysqjDodkZDtlTIkwXElxDK6662B1ltttjm1001t9W639FV+kVKnEzc61mT1PbXQxwt
xunNE7HgzVZn3Nssqy8ina22mqlrMXEyP+592Nh59emkkkkkks/K6Ztvd1Hpra6Oouj1SRtZktaA
xtGc5jXPdtY39Wy9ll+D/g/VxvtWFllx8jF6ni2MfXLTuoy8S9oLmOI/S42TV76/5t//AAlGRRZX
fRZdjXVW2V+m3W4dtfRct7rra6S/EynEudfRUa6bH5Lj7m5tDr6G5X+DyvWZlY/85kYmDppJJJJJ
JJJJJJJJJJJLJ+tn/iV6z/4Qyv8AzzYuA/8AzE/6/wDlgv/T1f8AHX/4lcX/AMP1/wDnnKXoCSSS
waqupdQ6l1UDquTiVYmSyimmhmKWhpxcPKcS7Kw8m5z3XZNv+FVj9jdR/wDL3P8A8zB/+RqX7G6j
/wCXuf8A5mD/API1L9jdR/8AL3P/AMzB/wDkal+xuo/+Xuf/AJmD/wDI1L9jdR/8vc//ADMH/wCR
qX7G6j/5e5/+Zg//ACNS/Y3Uf/L3P/zMH/5GpfsbqP8A5e5/+Zg//I1L9jdR/wDL3P8A8zB/+RqX
7G6j/wCXuf8A5mD/API1L9jdR/8AL3P/AMzB/wDkal+xuo/+Xuf/AJmD/wDI1L9jdR/8vc//ADMH
/wCRqX7G6j/5e5/+Zg//ACNS/Y3Uf/L3P/zMH/5GpfsbqP8A5e5/+Zg//I1L9jdR/wDL3P8A8zB/
+Rqr21dS6f1LpQPVcnLqy8l9F1N7MUNLRi5mU0h2Lh41zXtuxqv8Kt5JJJBysvFwqHZOZdXjY9cb
7rXBjGyQxu6ywtY3c921Z/8Aziou06diZfUTyDTSa63M/wBPTm9QODgZNTvb6f2bKu9Zj/Wp9Snf
Yl6n1nyf5unE6aw+5r7nPy7I/NpuxKPsFNNuv6SynqeZVW9npV/aN/2hL9mdau92T1myl40DcGii
quP3ns6gzq93q/ym5LKtnp/oPp2Wr9jdR/8AL3P/AMzB/wDkal+xuo/+Xuf/AJmD/wDI1L9jdR/8
vc//ADMH/wCRqX7O67R/Rer+tu+n9vxq7Yj6Pofs13Rtn/C+t9p/wfp+j+k9VfbfrBjf0np1eYwe
0Pwb2+o4/wCmfidQGFTjVPj+bb1PMtpf6dX6x78hL/nN0mvTOfZ0wjRxzq349Yf+dQzNva3AyLfp
f0TKyPVYyy6j1af0i1kkkkkkkkkkkkkkkkkkkkkkkklk5n+VM89LGuFi7bOpTqy31G2ej0w7f+tZ
mdW9/wDRfsmPZRk4nU7vSNlZV+Re7p/T3bLWR9ry4DhjhwD211teHV29Qtrdvppf+ixqv1zM/R/Z
MTqFrFxaMOhuPjt2VMmBJcSXEvsssseXWW222OdZddY71brf0tv6RGSSSSSSSSVTOwftOy6l/wBn
zceTj5AG7buj1Kra5Z6+JfsZ9ox9/v8A0dtVlGXRjZNCwc77TvpuZ9nzceBkY5O7bun07arIZ6+J
fsf9nyNnv/SVW10ZdGTjUW0kHLyqMLFuzMl3p4+NW6258E7WMBssdtYHPdtY381VcXFvyL29Q6g3
ZayfsmJIcMcOBY6yxzC6u3qFtbtl1zP0WNV+p4f6P7Xl9Q0EkkkkkkklRzcK11ozsEtrzq27PfIr
urBLvsuVtDnbNznuxslrH3YVz/Ur9ai7Mw8sVgq670v1MdzsXIa6wY9zmg2Y2VSbMV7trH7LH417
bqL2Mufi5lPrUepfh5H6Sx03O+20Oc9no5FNj6MmidxZZWdrtYY91VrNmTi2WVUvvw78fI9Kv1lb
SSSSSSSSSSSSSSSSWT9bP/Er1n/whlf+ebFwH/5if9f/ACwX/9TV/wAdf/iVxf8Aw/X/AOecpegJ
JJLJ6N/yj13/AMPs/wDbHpq1kkklC66qip91z21VVNL7LHkNa1rRue973e1rGtUMTKozcWnMxnep
j5NbbaXwRuY8Cyt214a9u5jvzlNl1VjrGVva91LtlrWkEtcWtt2WAfQf6Vldn9SxTQcbKoy6zbju
3sbZZUTBHvpe/Gvb7g36F1VjEZJJJJJJJZPWf+Uehf8Ah9//ALY9SWskq+b1DCwKhbmXNpa92ysH
Vz3kFzKMeps25GRZt/RY9LLLrf8AB1qj9o6z1HTEr/ZmI7/tTkNDsl7T+djYP83i763+pTf1B/r0
XM9HL6KjYvRMWm9uZkPsz85k7MvKIe9kg1u+zV1tqxcLfV+iu+w4+N9p/wC1PrWe9aCSSSSSSSSy
f+bmFRr0l9nRifpDBFbK3D87fhX1ZGB6rvZ+tfZftmyqun7R6P6NL9odVwNOqY32qkf9rcBj3x/x
/S5yM2r3OZVV9js6pv8A0mRkfYqloYuXi5tDcnDuryceydl1Tg9joJY7bZWXMdte3ajJJJJJJJJJ
JJJJJJJJJJJKp1LO+xUNcxnrZF1jKMaidpfZYdrdYe9tVTN+TlWV1XPow6MjI9Kz0VSeLeh9Erxs
dzcnqVzvTpc9pDbs3Ic627JsoY/ezH+0WX9QzKsf+i4VeT6P6OhaGFhVYVRYwusssd6l99kGy2wg
Nddc5oa3ftaxjWsYymmllePj1049NVTLCSSSSSSSSSSzOsU247T1bCY52XjNHrVVgudkY7Hepfi+
i3+fyG1Ovs6Z9D0832eszGys2u/QpuqvqZdS9ttVrQ+uxhDmua4bmPY9vtcxzVNZOT/lPqowOcLA
9PIyyPzskPZkdPxvUbu/o3o/bsun9Dd+k6V/OYmTkVWaySSSSSSSSSSybv8AJnVmXt0w+q2bMonU
My9ldOFfvdHpVZNOP9gs9/vzP2ZXjU+rkZVlqzv8m9So6gz24uZY3Fz2jg2W7KOnZrm+7da25tXT
XekzfbVmUWZNv2fplWzWSSSSSSSSSSSSSSSSWT9bP/Er1n/whlf+ebFwH/5if9f/ACwX/9XV/wAd
f/iVxf8Aw/X/AOecpegJJJLJ6N/yj13/AMPs/wDbHpqpfWLJxa+tdOpz867B6fZjZjrzXa/Hrc5l
nTxR9pyqdjsVjXWO9K/18b9N+qet+t/ZsmrhDI6jldNxrsvJGG+nqj2+lc+s30U5mJT0qx+VW5uT
az7FZTdTmV3/AGjKZ/OZN1OVk/aIfba/tG77dZ/zh/afpfYPtL932T7b6E/sb1fs/pfsL9Y9f7F/
Mf5S9T1f1pTy3dQzBdg4mbdVVfd1CnpmWXOa5+aa8prsTIsre+5mF0+77e7Df9m/7z6P5n7Dh39c
1ei5tvU83K6iwXVYTqceiui+WubfX62Rmn0pfU19f2yjAyff6n23AysW3+iqX1T/APEr0b/whi/+
ea1exnVOuyxXjupc24C2xzA0XO9Kh32it4/n2NqdXi+r+/jeh/gVy/X80Y3Vrzbl7rW7HY2OzOuw
8poDGbaendH9J+D162y/1LMezI31ZeXb+yr/ANHiITs6s5eGzqvUcjFwX2daFzxc+lh9HqFVOGzJ
y6y1+LVQw+lj2evjf4LB9X08n7Lkbv1f6g1+JRjXXOstudmPw3O3PNmJj5Joxb/tDt3rs+yX4Hp5
Flnq5jLftPqX/pLVz+d1ayrrLTj2uGT+0aaLK7M683sqflV4djrfq9TQem0YVuPZ6eFl3vr9THvw
s31v2nkVepXq63dXm4zsWzIe+/7QMtlWZbm5rduLl5bcfJ6Pfj/sjpPVXZGPW9mHV/2pouwsam3C
+1q30TrdNHW66ftFbsG/HfvfRn5PVa3XnIwcPEr+05lLWY9rH5+2ynGt+hk1XZ3p1/ZLFpdXyOnN
61ZV1vPdgYTcal2ETl2YLX2usym5223HuxPtT66q8DfW99v2b1K/5r7T+lzeo51baupvu6jkM6vT
W09Botufi3X/AKpj3Yr/ANj1nDpzrb+qvya3129Ps9XI9TA9LZR9lrsZ7LHZXVcr7Rktsr6rg4Vb
WZN7K20ZLOk05NbMau1uOx72Z2V+n9L7RTdZ9optrvrqsWv0Ivru6phepZZThZbasf1Xute1jsbD
y3NdkXusyLv1jKvf+mts/wBF/NV1sS6z/wAo9C/8Pv8A/bHqS1lk/tPK6l/yC7HsxuHdTtJtp3c7
MOih1f7Q2x6WRZ9sxaMex/stysijLxKbGF0nHxbTlPc7Lz3t2Pz7ww3lkhwoDqa6aqcduxv6vj1U
0+p+sen9ptuusvJJJJJJJJJJJJLPyukMfe7NwLPsGe+PVyK2NcLg0BtdWfU4frVTNjPz6cymr1Ks
TMxfXu3rF6rN7cHqTa8LqNkmqgWb2XNAL3Pwbnsx35PpMH6zX6Fd+N/hKvs1uLk5Ogkkkkkkkkkk
kkkkkkkkksnpv+Uc13Wj/RxW/F6c3ua/UnKzdzfY+rqT8fFfi/zzPseNj5VNv69fRWq/176wXPd7
sfpNbaqh2GXe31skvY//AAuPgOwvs19f+C6lnUepb6ltdOskkkkkkkkkkkksnp/6h1XJ6WdKcrfn
4XlveP2pR+c79Fm5FeZ6tr/f+1Ps+PX6WEtDLyqMLFuzMl3p4+NW6258E7WMBssdtYHPdtY381Ve
hYt+P02t+Y3Zn5X6zniQ4i+333Veo0v31Yv9Dxf0lvp4ePj0+rZ6S0EkkkkkkkkkkHLxaM3Fuw8l
vqY+TW6q5kkbmPBrsbuYWvbuY781Z/TP8rdCfi9S/WN32jAzH/Q9b0bLum5F+2nZ6H2v0X3elV/M
er6fqez1EbomVfdivx8x2/OwLDi5b4A3vYG2V5O2sekz7bi24+d6NX9G+0/Zv5yl60Ekkkkkkkkk
kkkkklk/Wz/xK9Z/8IZX/nmxcB/+Yn/X/wAsF//W1f8AHX/4lcX/AMP1/wDnnKXoCSSSyejf8o9d
/wDD7P8A2x6atB2LQ/KrzHNnIprsqrfJ0ZaarLm7Z2e9+NR/mIyShdU26p9Ty4NsaWuLHOY6HDad
ltRZbW//AISt+9ihi4tGHQ3Hx27KmTAkuJLiX2WWWPLrLbbbHOsuusd6t1v6W39IjJJILsWh+VXm
ObORTXZVW+Toy01WXN2zs978aj/MRkkkkkkklj9fuqozOi3XPbVVVm2vsseQ1rWtwOpOe973e1rG
tUvTyusaZVX2fpLtRQ8kXZLfzWZ1L2M+yYn+Efhb7b8ut9VOf9k/XenZGskkkkkkkkkkkkkkkg5W
LRmUOx8hu+p8SJLSC0h9dldjC2yq2qxrbKbq3erTb+lq/SKlTl5uDazG6ntsoe4VY3UWmN7yYqrz
6W111YmRdubVTbS5+Ll5H/cC7Jw8CzTSSSSSSSSSSSSSSSSSWZ1+60YTMPHe6vJ6lczErcwlr2tf
L826i3/BZGN06rMysex/+Gor/nn/AKGy7+q4OL/g8bExq/Kuuuusf2a6qqq2/wBRjFS+rtNrelsy
chjq8rPc7MyGWAixjsg+szFuL/e9+BQ6np7XP/wOJX+ip/ma9NJJJJJJJJJJJJZPWv0OZ0nO+gyn
L9HItHPp5NduJVS7b731X9Ts6Zur+h6rKMi3+j+rUvrF+moxOnDnqOXTSQfoOrrJ6hm03/vVZOBg
5WN6e17LvW9G79DZY9aySSSSSSSSSSSSycD9W671PFf/ANrfSz6nnTd+jr6bkUVt/wAL9l+w4t11
rfoftGit9bP0dl66h+odVxuqDSnK2YGb5b3n9l3/AJzv0WbkWYfpVM9/7U+0ZFnpYS1kkkkkkkkk
kkkkkklk/Wz/AMSvWf8Awhlf+ebFwH/5if8AX/ywX//X1f8AHX/4lcX/AMP1/wDnnKXoCSSS5/G6
lT03qnWGZVGX+ny2W0vqw8m9jmfZMGjc27Fx7qv52m2v6f5itf8AOXp3+hz/AP3HZ3/vGl/zl6d/
oc//ANx2d/7xpf8AOXp3+hz/AP3HZ3/vGl/zl6d/oc//ANx2d/7xpf8AOXp3+hz/AP3HZ3/vGl/z
l6d/oc//ANx2d/7xpf8AOXp3+hz/AP3HZ3/vGl/zl6d/oc//ANx2d/7xpf8AOXp3+hz/AP3HZ3/v
Gl/zl6d/oc//ANx2d/7xpf8AOXp3+hz/AP3HZ3/vGl/zl6d/oc//ANx2d/7xpf8AOXp3+hz/AP3H
Z3/vGl/zl6d/oc//ANx2d/7xpf8AOXp3+hz/AP3HZ3/vGl/zl6d/oc//ANx2d/7xpf8AOXp3+hz/
AP3HZ3/vGs/I6l0/r2b0M4lGRk49eX9r9W3DyGUhgxcz7PkjIyserH/pFuM6h/qfznp+kumSSSSS
SSSSSSSSSSSSULqar6n03MbbVa0ssreA5rmuG17Hsd7XMc1Z9F1vTsqnp+S912PkuLMDIeS6wOax
97sLKc6X2vZRTdbjZrv56mr0s39crryepaaSSSSSSSSSSSSSSSSyf6Z9ZPGnpWP/AFmHJyj/AJtO
Xg4WP/x32XrP+Bqs/WV9aPf0W7GP0M6yjBtPcV5l9PT8h9f/AArKcmx1O72er/g7PoLWSSSSSSSS
SSSSSWT9afZ0LKyufsHp5+z9/wCxWV9S9Dd+Z6/2X0fV/wAF6nqenZ/NpZ/6b6wdKxnaMprys5pH
PqVNp6exjv8AgvR6vkud+f6rKP0n84y3WSUBdUbXUh7TaxrXvrBG4NeXtre5n0mssdVbs/4uxK66
qip91z21VVNL7LHkNa1rRue973e1rGtQsLqPT+oVG7AyacuprtjrKLG2NDgA4sL6nObv2uaisuqs
dYyt7Xupdsta0glri1tuywD6D/Ssrs/qWJMuqsdYyt7Xupdsta0glri1tuywD6D/AErK7P6liTLq
rHWMre17qXbLWtIJa4tbbssA+g/0rK7P6limkkkksnqP6DrvSMr6XrfacDZxHq1t6l6+7+R+xvR9
L/uz6nqfofTt0MvFozcW7DyW+pj5NbqrmSRuY8Guxu5ha9u5jvzVV6DlX5XTGOyXepkUWXYt10Bv
qPxbrcGzJ9NgDKvtL8f7R6Lf5n1PSWgkkkkkkkkkkkkkksn62f8AiV6z/wCEMr/zzYuA/wDzE/6/
+WC//9DV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJJJJJJJJJJJLJzf8sWZPSGaYNf6HqdnDn+ox
lp6fR+c31ca+p+Xl/wCCou9HD/W7LMjpuskkkkkkkkkkkkkkkkkkkq/UMKrPwrsO0uY25sCxkB7H
D3VZFD3B3p5GPaGXY9v+CurrsQem5tt7r8TLDW5uG5rbtktZY17d9OZj1vLrW49/vr92/wBLKoy8
T18n7L9osvJJJJJJJJJJJJJJJLJ+rH6Xo1Ge7W3qk59hOrh9pP2imh9n0rvsWM+jBrt/0GLV+jqr
/RMX1l/5Op/8P9O/9vsNaySxMz60dPGFlW4t2y2vHutxr8mjIbi2Gut97XVZPotrzavTrdkfqFl9
t2JXbfj+pWrF/wBY+j4+Vdi2XO9XFcG5W2q17adzGXstzLqq304mO6m31PtOQ+rH9l/6X9WyPSnZ
nZTOv4/Ttlf2S/EvyPUkmz1KbMWrZshtbKvTy/pb7H2v/wBD6P6wuu9T/ZXTxml1bGNyMau19phj
a7sijFyLHO3M2enTdY/e72MVTP8ArNh1dPfmUP8AS9DIxK8huZXZjGunIyKcWzIfVmNxbWVek/I9
HJ/o/q0WfT9C5iWf9ZsOrp78yh/pehkYleQ3MrsxjXTkZFOLZkPqzG4trKvSfkejk/0f1aLPp+hc
xaGD1TDz94xzY19Ub6r6rKLAHT6dn2fLrou9KzZY2u70/SsfVb/orELK690zEvdRe+yao9exlN1l
NUgP/W8umqzFxNtTmX2fabqvSx3syLf0L/USyuvdMxL3UXvsmqPXsZTdZTVID/1vLpqsxcTbU5l9
n2m6r0sd7Mi39C/1FC/6xdKx8q7Fsfd6mO4Muc3HvfWHuYy6qj7TXS/HdkXMup9DHbb61111OPVX
69tdat4Wfi59RtxnOIY7ZYyxj6rGOADtl2PkNqvpfsey1vq1/wAzZXd/NWMVhZP1s/8AEr1n/wAI
ZX/nmxLJ/wDFV07/AMIZ3/n7pS1lj9eu6kLcanBfcA9tj7K8M4v2s7DU1j62dX/VHYVfqv8Ate39
Y9ezA9P9F66wruuZlVeZk15ddVtNfTKrMvJpraayepZ3Ts1uf6bm12/Z66rKcn0MmrD9X7TldO+y
V5C1TYyjJzen9XyrM3ExK8HOruua0Xes+/I9CljOnVYrbv1np2L9loZjvyL8i30P1j1aqFdw6nVZ
F/V+oFuLbmNox20Oc2K2Mfb9jptslzLM26/Os9T0X+jvspxMf7R6X2vLwsnIzMa/6152Jn+k/pdg
yxhMbW71C3Aw7Gfbjc2677Jf9m9Gv7L9it9mX+s2fo/sqycjMxr/AK152Jn+k/pdgyxhMbW71C3A
w7Gfbjc2677Jf9m9Gv7L9it9mX+s2fo/sqycjMxr/rXnYmf6T+l2DLGExtbvULcDDsZ9uNzbrvsl
/wBm9Gv7L9it9mX+s2fo/su71rqDqcF/2O5ov+04uHY5u1zqjk3Y2O92x29jcivHzPtFHrVvZ/Mv
sptpVTNtzum4ltLepuy77LsOoOtZT9opbl5LMB9/6vXRjuZsc9+F62F/SaLvW+10/q9NXPy+q4T8
rprOoXWOa7pbq82xlHrsGdmv6fk1tbXjV4extGP+h9TEe/1Lbf5z9F6SOX1XFtybHdQuyG9P6jid
PFVrKA25mUcA23ZPoY1Nv2ir9q2eh9lsxqf1bF9Wi79Z+09QsnrP/KPQv/D7/wD2x6ktZZOB+rdd
6niv/wC1vpZ9Tzpu/R19NyKK2/4X7L9hxbrrW/Q/aNFb62fo7L9ZJJJJJJJJJJJJJJZP1s/8SvWf
/CGV/wCebFwH/wCYn/X/AMsF/9HV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJJJJJJJJJJKj1jNt
w8InGDX5t7hRhVvktdfZ7azYxhba7Ho92Vmel+kqwqMm/wDwSN0/CqwMKnDqLntpbBsfBe9x91uR
e9ob6mRkWl92Rb/hbrLLFYSSSSSSSSSSSSSSSSSSSSWZ1ym1lVXU8VjrMrprjaK6wS+2gjbnYbWM
99z7qP0uLj72V2dSx+nvu/mVoU3VX1Mupe22q1ofXYwhzXNcNzHse32uY5qmkkkkkkkkkkkkksn6
0+/oWVi8fb/TwN/7n22yvpvr7fz/AEPtXrel/hfT9P1K/wCcWssn60ezot2SfoYNlGdaO5rw76eo
ZDK/+FfTjWNp3ez1f8JX9NayS5K/6sdZtxMvCpNOJXdjZGOCzLyraLBZTZj00s6Vksfi9Hx23WU5
P6lbkvxK8f7BT6tF1iLkdN61l2/WLBqrpbhdVu9E3XGyt9bbMHCxbcvHa2u6rqDPptbTvwv02LZX
9q/Tfqu1bhWv61i54LfSx8bJoe0zuLr7MK2stEbdm3Dt3+7/AEar9Xweq5+Hfj1Px6nty8W/Ce4P
cBXRZiZdn2qsFnqW+tRlbK6rKmWVfZ/0tX6SxUsvovWs/wC05Vn2bEzbndPbVW19mRU1uBlO6j61
jzVgW2Pt9eyv7Nsq/mf6X+n/AFdZfRetZ/2nKs+zYmbc7p7aq2vsyKmtwMp3UfWseasC2x9vr2V/
ZtlX8z/S/wBP+r28fE619ryOpWsxqMrIbiY/oNssurFFF112Rb65pw3/AGi2jOyGUVeh6dd1NPqX
P9X9EjidaxM7NfgMxrKuo3NvddfZY11LhTj4JAxKqbG5jGNxG5H9NwvV9T7P+h/pCr9R6P1W5vV8
PGbjuxOuT62RZa9llHqY9PTLPTxWY91eX6deN9pZuy8T1X2fZ/0X9IRcjomVb9v2vrH2vqeFnVyT
pXjfs31mP9v8679nX+n+Z/NfpP3LvT8K3Gy+pXWFpbm5Lb6g2ZDW42JhxZIHv9XFs/sK8sn61e/6
v5uMPp51f2Go9hZmOb0/HfZ/wTLsmt1233+l/g7PoJZ/6H6wdKyXasurysFoHPqWtp6gx7v+C9Hp
GS135/qvo/R/zj6tZV83p3T+oVCnPxqcuprt7a7622NDgC0PDLWubv2ucg39H6fdSyltTaG1uxi0
0taw7cO1uZh4/wBH+j12s/mvzGWW+l6aTOh9FrwrMCvp+MzCudvtxW01ipzht99lAZ6T3/o6/wA3
/BpYvQ+i4bXsxOn42O2xzHvbVTWwOdU71cd7xWxu59Fv6Sn/AET1O7pPSr72ZN+Hj25FdnrV3PqY
57bIrZ6zLHN3tt2Y+O31Pp/oKf8ARJXdJ6VfezJvw8e3Irs9au59THPbZFbPWZY5u9tuzHx2+p9P
9BT/AKJK7pPSr72ZN+Hj25FdnrV3PqY57bIrZ6zLHN3tt2Y+O31Pp/oKf9EiuxMV7L6301uZlT9p
aWgi2Wtod67Y/S7qWMp/Sf4L9GhY/SelYuLZhY2Hj0Yl+71seupjK37x6dnqVMaK376xsfu/MSxu
k9KxKDjYuHj0Y5sbcaaqmMZ6jSx9d3psa1nqsfVU5ln0/wBFWiuxMV2/dTWfUsZdZLQd1lfp+jc/
T3W1ehR6dn02ejV/o0ZZPU/03WujYzdH02X5ziePTqof097G/wDC+t1fGc38z0mX/pP5tlussnrX
6tldO6o3T0cgYl8audTmlmIKmNd7P+Uv2ZkWP/nGUY1vp/6C/WSSSSSSSSSSSSSSWT9bP/Er1n/w
hlf+ebFwH/5if9f/ACwX/9LV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJJJJJJJJJJLJxP8AKfUn
9Qd/Ren2XYuE3kPsbtozc17XfQtouryem43sreyr7dZ6t+P1Gv0tZJJJJJJJJJJJJJJJJJJJJJJZ
PTf8nZruin+jmt+V053cV+pGVhbW+xlXTX5GKzF/mWfY8nHxaav1G++zWSSSSSSSSSSSSSWT179L
Z0rCdpVl59fqEfSH2Zl/V6dn5vuyenUMs/4D1f8ACfpWayhdTVfU+m5jbarWlllbwHNc1w2vY9jv
a5jmrP8Aq7da7pbMbIe6zKwHOw8h9hJse7HPosyrg/3sfn0Np6g1r/8AA5df6W7+es00kkkkkkkk
kkklk9a/TZnScH6bLsv1sioc+njV25dVztvvZVR1Ovpm6z6Hqvox7f6R6Vq+sX6GjE6iOenZdNxJ
+g2uwnp+bdf+7VjYGdlZPqbmMp9H1rv0NdjFrJJJJJJJJJJJJLJwP1nrvU8p/wD2i9LAqYddv6Ov
qWRfW7/Bfavt2LTdU36f7OosfY/9HXRrLJ+tXs+r+bkj6eDX9uqHY2Ybm9Qx2Wf8E+7Grbdt9/pf
4Sv6a1kkkkkkkkkkkkkklk/Wz/xK9Z/8IZX/AJ5sXAf/AJif9f8AywX/09X/AB1/+JXF/wDD9f8A
55yl6AkkkkkkkkkkkkkkkkkkqnVc79ndNyc0M9Z9FZdVRO022fRx8Wsw/wDS5Nxrx6drHv8AVs+g
l0nB/ZvSsPp2/wBX7Hj1Y/qRt3ekxtW/ZL9m/Z9HeraSSSSSSSSSSSSSSSSSSSSSSyfrN+h6VZ1R
n890ic+rz9Fln2ij939bwn5WH6rmWfZ/tH2hlfq01rWSSSSSSSSSSSSSWTn/AKb6wdKxnaMprys5
pHPqVNp6exjv+C9Hq+S535/qso/SfzjLdZJZNf6j9YLmO9uP1atttR7HLob6OSHvf/hcjAbhfZqK
/wDBdNzr/Tq9O2y7WSSSSSSSSSSSSWT0/wDX+q5PVDrTi78DC89jx+1L/wA136XNx68P0rWez9l/
aMez0s1aGXi0ZuLdh5LfUx8mt1VzJI3MeDXY3cwte3cx35qq9Cyr8jptbMx2/Pxf1bPMBpN9Xsut
9NoZsqyv6Zi/o6vUw8jHu9Kv1VoJJJJJJJJJJIOXlUYWLdmZLvTx8at1tz4J2sYDZY7awOe7axv5
qq9Bxb8XpjG5LfTyL7Lsq6mQ7035V1udZjeowllv2Z+R9n9Zv896fqrQVTq2D+0ulZnTt/pfbMe3
H9SN231WOq37JZv2b/o70uk537S6Vh9R2el9sx6sj053bfVY23Zvhm/Zv+lsVtJJJJJJJJJJJJJZ
P1s/8SvWf/CGV/55sXAf/mJ/1/8ALBf/1NX/AB1/+JXF/wDD9f8A55yl6Akkkkkkkkkkkkkkkkkk
snrn6e/pnThqMjLZdcG/TbXiB3UGXD92r7fj9Pxr7HN2frfo/o7r6HrWSSSSSSSSSSSSSSSSSSSS
SSSSWT9VvZ0LFxefsHqYG/8Af+xWWdN9fb+Z6/2X1vS/wXqen6ln84tZJJJJJJJJJJJJZOT/AOKr
p3/hDO/8/dKWskqPWMK3MwiMYtZm0OF+FY+Q1t9furFj2B1rce/3YuZ6X6S3CvyaP8KjYWbVm1F7
A6uyt3p30WQLKrAA51NzWlzd+1zHtcx76bqX15GPZdj3VWvsJJJJJJJJJJLM6xdbkNPScJ7m5eS0
etbWS12Pjvd6d+V6zf5jIdU2+vpn0/Uzff6L8bFzbKNCmmqiplNLG1VVNDK62ANa1rRtYxjG+1rG
tU1k5P8Akzqoz+MLP9PHywPzckvZj9PyfTbt/pPrfYcu79Nd+j6V/N4mNkW16ySSSSSSSSSSybv8
p9WZQ3XD6VZvygdA/L2V3YVGx0+rVjU5H2+z2ezM/ZlmNd6uPlV1aySSyfqn/wCJXo3/AIQxf/PN
a1kkkkkkkkkkkkklk/Wz/wASvWf/AAhlf+ebFwH/AOYn/X/ywX//1dX/AB1/+JXF/wDD9f8A55yl
6Akkkkkkkkkkkkkkkkkkslv6f61Wb9PsGBX6Ud/tt1v2j1P6n7GxfR2/6S/f6n6P0tZJJJJJJBxM
qjNxaczGd6mPk1ttpfBG5jwLK3bXhr27mO/ORkkkkkkkkkkkkkkkklk9E9ub1upulVeePTYNGt9T
Fwcq7Y36LfVyb78iz9++623+csWskkkkkkkkkkkksnJ/8VXTv/CGd/5+6UtZJJZmfTbg2u6phMc8
ucz7fjMBd6tctqflMrZuf9tw6Pf+hZZdnY9P2D0brf2fZh6FN1V9TLqXttqtaH12MIc1zXDcx7Ht
9rmOappJJJJJJJKp1PO+w4rrWM9fJfLMTFB2uuuIc6rHY6H7N+z9Jbt9PGo9XKv/AFem16WDg/Zt
91z/ALRm5EHIyCNu7bPp1VVy/wBDEo3v+z4+/wBn6S22y/Lvycm+2kg5eLRm4t2Hkt9THya3VXMk
jcx4NdjdzC17dzHfmqr0/Kvbfb03Oduyafdj3OAaciiGfrWxg9L1abbPsuYyn/C+llfZ8THz8Sha
CSSSSSSSSo9TzbcdtePiBtmflODaK3SQG7mNycy1jSz9XwqrPWs/S0es/wBHC9evJy8dGwMKrAxW
41Rc8Bz7H2PgufZa92RkXP2hjN919tlu2pldP+hrrq9isJJLJ+qf/iV6N/4Qxf8AzzWtZJJJJJJJ
JJJJJJZP1s/8SvWf/CGV/wCebFwH/wCYn/X/AMsF/9bV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJ
JJJJJJJJJLJ6N/yj13/w+z/2x6atZJJJJQuFpqeKXNZaWkVve0vaHR7HPra+p1jGu/M9Wv8A4xc5
iB+JlUnKOfg5j7GssvyrnZeHkFxDL62eld9jwfXscz7A9+L0S37RZj04uJ6X2npiFQ/KzOhfVJj8
vIrdneiMu2uwtstaen5eRayy7+c/TWV++z+fY/8AT0W05LKr69PGrPTetUdOotusxcvGyMhzci2z
Ic2zHsw6muqvyn3XtZczN/S1Ot9H9DT6DKf1n7Rd6pd6GBbZ9o+yfRb64Z6rxuc1m3Hp93q5du70
sNnp3/rT6f1XK/o1uFiX5WD1Xp9NWF1HEoz7n0XnqGUzLYdtGTmVmn/KHUcijIa/F/M9PHspsv8A
tHqXfZPRqdRzcrG6fk9axKuo51+PTZks6ky5jMCz02uednSrs9rf2Ztb6O+vBtyLsX9cxMvJyn09
St2Otn1cpmNGXl7axZ9g6dZ9msbJcz7Xl5v2rA/RO2+jiYv2ir1X/a7fRzfs+/p0/q3mZV9edj5F
d1P2DJ+z0syXMfeKzRjZbG5F1FuTVc9n2rZXb61lz8f0ftT7cv17bFk1nqXWr+nX23V4uJjY+Q1u
PbZjudZkWZlTnW34r6b3MpZhfoqm2+j+mu9dl36t9nhmsysVuB0v7VY+jPy3Y/qyRkMx24+Tm+h9
r3Osfb6mJ9n+2/0v7JZ/O/tH/KSTsYdH6h05mJbkPq6hkPxsivJyLskQ3Hys2u2o5lt9lNrLMT0/
0T/Ssqut9eq2z7NZj4+LjZDPqr0nqzeoZp6llN6a1+S7Ie8AZdmLi3fqVpf01724+S9ldl2Fa/f+
s3erl/rC2MfGHTev42HjW5DsfKxMm25mRkXZMvoswa6HMdm25D6drMzI3ej6fq/4Xf6VWzbSSSSS
WTjf+KrqP/hDB/8AP3VVrJJJJJJJJJJJJLJzf0X1k6Xe/SqzHzMRjuZusOJm11QPd7sbp2bZv/m/
0P8ApLKt+skkksy7ptuHa/L6LXTXbc4uysR5NVF7nGXZL7Ka73UZrXf9qm0Xfaq/1fKZZ+qZGDYw
ep4udvZU7Zk0QMrEeQLqXOnazIqa5+zfsd6Vn8xk1/p8W27H2Wq2kkkkkks/K6rF7sHpra83qNcG
2g2bGUtID2vzrmMyH43qsP6tX6Fl+T/g6vs1WVk40sLpdWPacy/bk9SsbtuzC0B20kO+zY/03Y2E
xzf0WK2z/hr35GXZflXXkkklXzen4WfUKsyltzWO31k6OY8AtZfj2ti3HyK936LIpfXdV/g7FR/a
N/SvZ1p9Ywx7auqlwY0n80dSr2VU4Vr/AObrvrf9jyr/APyvtyMPBs1kkkkkkln5XU917undNdXf
1FseqCdzMZrgHtvzmsc17dzHfq2Jvrvzv8H6WN9qzcQuD0zFwd76m78m+DlZbwDdc5s7X5FrWs37
N7vSr/mMav8AQYtVOPsqVtJJBy8qjCxbszJd6ePjVutufBO1jAbLHbWBz3bWN/NVX6vYt+F0DpmH
kt9PIxsSiq5kg7XsrZXY3cwuY7a9v5q0Ekkkkkkkkkkkklk/Wz/xK9Z/8IZX/nmxcB/+Yn/X/wAs
F//X1f8AHX/4lcX/AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSyejf8o9d/8Ps/9semrWSSSSULqar6
n03MbbVa0ssreA5rmuG17Hsd7XMc1Z9PRA21hyM3JzMelwfRiZBrdWxzDND3WMpry8p+P/gvt2Tl
fptmVZ6mZVTkV18n6u7sPo2Bi32U09IsaRcH7btlWLk4VD2Oaz0rLfVuofZXbX9lur9Wu6qyr9Xs
u4XSxjWnIvybs/KLfTbkZHphzKyQ91NTMWnForY97d9rm0+tf+h9eyz7PjejM9Nofh2YeQ6zJqss
faXWvJe0vsdlV+lazZZT9ksc37E+v9Li+jR6VnqVb1Ub0Am+jJyuo5eZdiWC3GdaaWCskOru/Q4m
NjY932jHssx3vyar7aarLPsdmLb+lUbvqzj3VPwn5eSOlWNLHdLY5jKNjhrQy6qpnUa8f/uvXn+i
yv8AVPT+w/qqsZHSDb6dtWZkY2YyttVmbUKfUtY3Xbk1249uG/8ASOdaz9VZ9nfZd9l9CrIyK7YY
/Qqsdtwrysndk3U5ORYbAXvupdW59rn7PYzMqopxcnFq9PD+y1+hiY2L+kRc3pYybRkUZN2BlBvp
uyMf0y59YJe2m1mVTlUWMY92+pzqfWo/TehZX9oyfWj+xMX7L6O+z1/U+0fbpH2j7RHp/bPU2+n6
vp/ofS9L7J9k/wAn/Zv2d+qJYvSDVe3Iy8zI6jbVP2c5IpAqLgWWWVV4ePiV+q+t3p+ta222ur1a
qPSryMn1kzomKzpOH0kPs+z4P2X0nSN5+xvpvx/Udt2e9+NX621n/basPwqn9QpzyXerj020MaI2
lt7se2wuEbt+7Dq2e7/SKwkkkkksnG/8VXUf/CGD/wCfuqrWSSSSSSSSSSSSWT1v25vRLXaVV559
R50a31MXOxad7vot9XJvox6/377qqv5yxaySSSSqZ3TMXO2PtbsyaJOLlsAF1LnRufj2ua/Zv2N9
Wv8AmMmv9BlVXY++pVPW67gey2j9r08MtxzXTkj937Tj5VmPhW+1u67Lx8rH33WbKulU1fpEv+dH
RWa5N1mCztbnUX4dZP8Ao2ZHUKcal9v53ots9XZ6n+jer2F1Hp/UKjdgZNOXU12x1lFjbGhwAcWF
9TnN37XNVhUc3rnRen2inP6hjYlrm72133V1uLSS0PDLXtds3Ncq/wDzjw7fbg4+XnPd/Nejj2Nr
sHPqU9Qy243TH1bP0ld3230r2f0f1fUq3r7P1nqOuXZ+zMR3/abHcHZL2n83Jzv5vF31v9O6jp7P
XouZ62J1pL9qfVvpH+S6Lcei2j6PTMRofcN/6Y+l03Ca/J+i/wC0P9PH/m/1j+b96X7f9X+g9Nz8
yP5z9B9l2z9H/ll/TPW3+7+jev6f+G9P9F6i/bPUf/KLP/z8H/5JJftzJr9+V0fPx6R9O3bRft/d
/V+m5Wbm2bne39Di2/v2fovUsU6frJ0Sy1lD8puNk2uDasbLa7FveXHaz0cXObj5FrLH/o67K6tl
ln6P6bFppJLJ/Z/Uun/8kW12Yo+j03K9lbB+bXhZlDLLsSpu5z/Rvx+o1bPSxMP9n46X/OKinTqO
Jl9OPJN1Jsraz/T3ZvTznYGNU33ep9pyqfRYz1rvTp2WKxhdc6L1C004HUMbLta3e6ui6uxwaCGl
5ZU9ztm5zVeVfN6j0/p9Quz8mnEqc7Y2y+xtbS4guDA+1zW79rXKj/zm6ZZ/QxkZ+7Sp+Jj3W02O
/cq6gyv9m/T/AET7LMyuiiz+kW0+nYl9n6z1HXLs/ZmI7/tNjuDsl7T+bk5383i763+ndR09nr0X
M9bE60tDFxMXCobjYdNeNj1zspqaGMbJL3ba6w1jdz3bkZJJJZP1r1+rHVaxq+7Eupqb3fZax1GP
TW38+2+6yummtvvttf6a1kkkkkkkkkkkkkklk/Wz/wASvWf/AAhlf+ebFwH/AOYn/X/ywX//0NX/
AB1/+JXF/wDD9f8A55yl6AkkkkkkkkkkkkkkkkkksnpHs6p1yt3te7Lqua06E1uxMKhlzW/6J92N
k0ts+h6uPfX/AIKxaySSSSSSSSSSSSSSSSSSSSSSSSwf2j0/D691PNzMmnFxWU4eCbr7G1N+0M+2
Z78cOuczc/7Jn4t3/XP+Cu9Ox/zs+qv/AJc4H/sVT/6US/52fVX/AMucD/2Kp/8ASiX/ADs+qv8A
5c4H/sVT/wClEv8AnZ9Vf/LnA/8AYqn/ANKJf87Pqr/5c4H/ALFU/wDpRL/nZ9Vf/LnA/wDYqn/0
ol/zs+qv/lzgf+xVP/pRL/nZ9Vf/AC5wP/Yqn/0ol/zs+qv/AJc4H/sVT/6US/52fVX/AMucD/2K
p/8ASiX/ADs+qv8A5c4H/sVT/wClF57k/wCObqGF1rOx34eNndPputqxX0PdW5zW2baLzkTl02sf
S3/B0s3/AE11fR/8aX1P6o4VuyndPtc4tazNaKwQ1vqeochjrcStjvoN9XIY/f8A9bWr9YrqrehD
Nqe2zFpuxM59zCHN+z4+Rj5+RkMc2fVYzEpsu/Rfzv8AgfUWwkkkkkkkqOb0PovULRdn9Pxsu1rd
jbL6a7HBoJcGB9rHO2bnOVf/AJp/VX/ymwP/AGFp/wDSavYXTun9PqNOBjU4lTnb3V0VtraXEBpe
WVNa3fta1QzupUYWxjm2XZF0+hjUMNljy2J9rfZVU176q7MrJfRh0Puq+0ZFPqKp9h6l1L39Qvsw
8V2rcDFd6VgH5rc3qND3XOtbtZbt6bbh1VP9XGsv6nj/AKV+hi4mLhUNxsOmvGx652U1NDGNkl7t
tdYaxu57tyMkkoXU1X1PpuY22q1pZZW8BzXNcNr2PY72uY5qzP2F9j93Q7/2b/3V2erhn/0A30/Z
vpWWf5NvwPWyH+tmfakbF6tvvbh52PZg5j5DGP8AfTaWgud9kza/0Nu7ZdZXj2/Zuo/Z6X5FuBRU
tBJJV83p3T+oVCnPxqcuprt7a7622NDgC0PDLWubv2ucqP8AzT+qv/lNgf8AsLT/AOk1Ywuh9F6f
absDp+NiWubsdZRTXW4tJDiwvqY12zc1qvJJJJJJLJ+sP6WvAwm6W5efjemT9EfZn/te7f8Ane7G
6deyv/h/S/wf6Vmskkkkkkkkkkkkkksn62f+JXrP/hDK/wDPNi4D/wDMT/r/AOWC/9HV/wAdf/iV
xf8Aw/X/AOecpegJJJJJJJJJJJJJJJJJJLJ/mPrV+9+0cD4bPsN3/gn2j9t/yPS+zf4X1v0Wskkk
kkkkkkkkkkkkkkkkkkkkkuX/AObfRPrG/qdnVcVuXjHqLnYlhc5jgacfF6Zl7X0uqvYz7Zg5FL63
ey70K7v0jPQtUP8AxrfqJ/5Wf+D5H/vQl/41v1E/8rP/AAfI/wDehL/xrfqJ/wCVn/g+R/70Jf8A
jW/UT/ys/wDB8j/3oS/8a36if+Vn/g+R/wC9CX/jW/UT/wArP/B8j/3oS/8AGt+on/lZ/wCD5H/v
Ql/41v1E/wDKz/wfI/8AehL/AMa36if+Vn/g+R/70Jf+Nb9RP/Kz/wAHyP8A3oS/8a36if8AlZ/4
Pkf+9C89yf8AFJ9ZsnrWdXh49OF00XWuw7b7g5pq9SMeseicrK3+if8ADV/8Z+kXVdH/AMS/QcVw
s6pk3dSc1xPptH2eotLdrW2MrdZkb2P/AEm+vLq/4v8A0nYY31a6DidPv6di4NOPi5VP2fIbU3Y6
yva6rbfezbfa/ZY/9LZb63v+mp9Ayr8vo2JblO35jaxVmmAP1mk/Zs9vsDa/ZmVXs/Rfof8AQ/ol
oJJJJJJJJLPysq/Ivd0/p7tlrI+15cBwxw4B7a62vDq7eoW1u300v/RY1X65mfo/smJ1AuD0vA6f
vOLVttuj1r3udbdZtn0/tGXe63JyPSa7ZV61r/Sr/R1/o1bSSSSSSQcrExc2h2NmU15OPZG+m1oe
x0EPbursDmO2vbuVKm63plrMTLe63CtcGYmW8lzmOcdteFm2O9znud+jws2z+lf0TL/yh6F/VNNJ
JJJJJJJJJJZNP639ZL7xrV0vHGIxw0/TZJrzc2qwO9zvSxqOk2UvZ+j/AFq/+ds/o+skkkkkkkkk
kkkkksn62f8AiV6z/wCEMr/zzYuA/wDzE/6/+WC//9LV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJ
JJJJJJJJJLJ+sX6GjE6iOenZdNxJ+g2uwnp+bdf+7VjYGdlZPqbmMp9H1rv0NdjFrJJJJJJJJJJJ
JJJJJJJJJJJJKF11VFT7rntqqqaX2WPIa1rWjc973u9rWNas/wCrdNtfRMV97HVZOS12Xk1OBaWX
5TnZ2VTsd762VZGRbXXXZ+krZ/Ob3rTSSSSSSSSSSSSSWTh/qXXMrBHtx82sZ2M3t6gd6HVGVNb7
Kqmvf0/L9zd92Z1DMv8AUu/S+hrJJJJJJJKpnZ32bZTSz7Rm5EjHxwdu7bHqW22Q/wBDEo3s+0ZG
z2fo6qq78u/Gxr103B+xUOa9/rZF1j78m+NpfZYdztJe9tVTNmNi12W3Pow6MfH9Wz0VbSSSSSSS
SQcvFozcW7DyW+pj5NbqrmSRuY8Guxu5ha9u5jvzVV6flXtvt6bnO3ZNPux7nANORRDP1rYwel6t
Ntn2XMZT/hfSyvs+Jj5+JQtBJJJJJJJJJJZP1b/S4FnUT7ndTyLcttnHqUud6XTLdn+D/wAk04Hs
2Ms/7kfrPrLWSSSSSSSSSSSSSSWT9bP/ABK9Z/8ACGV/55sXAf8A5if9f/LBf//T1f8AHX/4lcX/
AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSDl4tGbi3YeS31MfJrdVcySNzHg12N3MLXt3Md+aqvQMq/
L6NiW5Tt+Y2sVZpgD9ZpP2bPb7A2v2ZlV7P0X6H/AEP6JaCSSSSSSSSSSSSSSSSSSSSSSyeu/rno
dDb/AN6W/wC1eWHVs+3/ALv9J9ajpv6OxmRT9v8AtlP9FWskkkkkkkkkkkkkksnr36t9j6qNPsGQ
31yPbONf+p5fq3f4PExfWq6pkb/0P+Ta/U9P+kU6ySSSSSSSqY32DLuPUaP0lrPUxPUO72+ja+rJ
qrZZ7a/1mn9M+tn6z6FH87XRjq2kkkkkkkkkkqme2ipn7SfRZfdgV22VNoBNzgW/pMepjXM9f19j
P1az9FZkV49n87TTZXYpuqvqZdS9ttVrQ+uxhDmua4bmPY9vtcxzVNJJJJJJJJZPXf1z0Oht/wC9
Lf8AavLDq2fb/wB3+k+tR039HYzIp+3/AGyn+irWSSSSSSSSSSSSSSSWT9bP/Er1n/whlf8Anmxc
B/8AmJ/1/wDLBf/U1f8AHX/4lcX/AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSSyf8Ak/rvhjdZ/DMo
r/tPd9s6bj/8Fj4/7J/7kZy1kkkkkkkkkkkkkkkkkkkkklC66qip91z21VVNL7LHkNa1rRue973e
1rGtWf0im223K6rkMdXbmuDKa3gtczFpL24bHsOx2+51uR1D9NVXlUfbvsV/9EWmkkkkkkkkkkkk
kkoXU1X1PpuY22q1pZZW8BzXNcNr2PY72uY5qz+i3W1Nf0nLe6zL6e1v6V5L3W473W14GVZcf5zI
tqx315m70/12nJf6P2azGst00kkkklR61m24HS8jJxw1+UGivErfJa/ItIx8Kl+0s9l2XbTVu31/
y7K/po3TsKrp/T8bApLnVYlNdFbnwXFtbW1MLy0Nbv2t/dVhBpyqL7L6qnbn4tgqvEEbXlleSG+4
e79DkUv9ijm5+LgVC3Jc4B7tlbK2Ptse4gu2U4+O22+5+xj7XelX/M12XfzVb0sLPxc+o24znEMd
ssZYx9VjHAB2y7HyG1X0v2PZa31a/wCZsru/mrGKWNlUZdZtx3b2NssqJgj30vfjXt9wb9C6qxiW
NlUZdZtx3b2NssqJgj30vfjXt9wb9C6qxiWNlUZdZtx3b2NssqJgj30vfjXt9wb9C6qxiMkkkksn
6u/oaMvpx56dl3UgD6Da7COoYVNH7tWNgZ2LjentYyn0fRp/Q11vWskkkkkkkksnoX656/XHf96W
z7L5YdW/7B+7/SfWv6l+krZkU/b/ALHd/RVrJJJJJJJJJJJJJJJLJ+tn/iV6z/4Qyv8AzzYuA/8A
zE/6/wDlgv/V1f8AHX/4lcX/AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSDlZeLhUOycy6vGx6433Wu
DGNkhjd1lhaxu57tqzWZOF9aeiWW9Osc2i127BzXM09WhzbaMyvHe5lj2YufT/M5TKfWfjfzf2Wz
1LbvTc77bQ5z2ejkU2PoyaJ3FllZ2u1hj3VWs2ZOLZZVS+/Dvx8j0q/WVtJJJJJJJJJJJJJJJJJJ
JJZPVv17Kx+it1qs/WOodwMas+zGf9Jv+UcnbR6N9fo5nTqerVfzla1kkkkkkkkkkkkkkkkln9Ux
by+nqOE3fnYctbXIAsosdU7Oxf0hbX6tteOyzFf6lH65Rj+rkfZPtXq2sTKozcWnMxnepj5NbbaX
wRuY8Cyt214a9u5jvzkZJJJJZPXP0mT0fFfrTkZ7fVZ+96FGV1LH930m+nm4WLd7f9F6b/0XqVrW
XL/WjIZT1CsZGZTVU6kelRkdQyOktDt1nq21ZWHW9vUX2N9FluO//k/0abP+9FZ9nUrX+k7MzM3E
xbOq1V3usJqvZQ7o7Mq2nLbjt2YbPXd62c6llFeDZ62ZXZiej9pq0MTqPT6sXIfbkud0tmaaumdW
dY29lDX4bHPzP2lnOyGuZ9uszsGvIufk/rV/7N/mv0CsfVrNxTk5tDMn7Y7KyH342bo77VXTR06j
IyfVxmV4Lvs197MD9VroZ+r/AM3Zk15dyx8HJxay4Y+dd+2P2xcyvBNr2g47+pWMzXUdN/R0ZuP9
jfmXW5z6Mv7O/wC0frVX2DZiLBycWsuGPnXftj9sXMrwTa9oOO/qVjM11HTf0dGbj/Y35l1uc+jL
+zv+0frVX2DZiLBycWsuGPnXftj9sXMrwTa9oOO/qVjM11HTf0dGbj/Y35l1uc+jL+zv+0frVX2D
ZibXWeo4t+D0vLGS6jo+bc1+VltsfjAY78fIvxn2ZbXUX4bLMxuCz+do3vf9l/w/o2ULcro4txa3
dVuH1fc3JP2x+ZbXX9oacL7Pj1dZFtN+WzZb1F/pOzsn9N9qq/7zvRw1hMs6nldNxsnIyTimnqj6
XVZN9JsqpzMSjpd78jFtpty2fs+1vo5Ftlv2hlv2n1LfV9VF+rl2QbejWvvutd1fpT83NFtj7Guv
aenObZRVc99WGz9eyv0GGzHx/f8AzX6Gj0+oWThfovrJ1ShmlVmPh5b28zdYcvCstk+73Y3TsKvZ
/N/of9JZbv1kkkkkkklk9d/XPQ6G3/vS3/avLDq2fb/3f6T61HTf0djMin7f9sp/oq1kkkkkkkkk
kkkkkkklk/Wz/wASvWf/AAhlf+ebFwH/AOYn/X/ywX//1tX/AB1/+JXF/wDD9f8A55yl6Akkkkkk
kkkkkkkkkkkuH+v/APjDzfqvazDxenOffc3dVmZH9HIBZu9JtL/Vve3c+u2uyzEfR+ht/TU2sXlt
F/1g+vP1gw8HOzLMi7Is2tc7bsqZtBybqcYGjHZsx6PWsrp9L7R6X+lX0JiYtGFi04eM308fGrbV
SySdrGAV1t3PLnu2sb+cqXVKbca39tYrHW241LmZGKwEuyKAfW2VtZ7rM3Gc17un+p+j/WMvF/Qf
bvtePoU3VX1Mupe22q1ofXYwhzXNcNzHse32uY5qmkkkkkkkkkkkkkkkkkkqnU877DiutYz18l8s
xMUHa664hzqsdjofs37P0lu308aj1cq/9Xptel03B+xUOa9/rZF1j78m+NpfZYdztJe9tVTNmNi1
2W3Pow6MfH9Wz0VbSSSSSSSSSSSSSSSSSWS7/JPUmuGnTupWBhYNG0ZbvVsN7t3sZV1N/p0O2ur/
AMp+h+hvyeq5NzNZJJJJZPWf+Uehf+H3/wDtj1JaySDdi0X2UW2t3PxbDbQZI2vLLMYu9p936HIu
Z70ZJJJJJJJJJZON/wCKrqP/AIQwf/P3VVrJJJJJJKv1DNqwMK7MtDntpbIrZBe9x9tWPQxxb6mR
kWllOPV/hbrK60HpmFbjtsyMstsz8pxdfY2SA3c92Nh1PcGfq+FVZ6Nf6Kj1n+tm+hXk5eQrySSS
SSSSSSSSSSSSSyfrZ/4les/+EMr/AM82LgP/AMxP+v8A5YL/19X/AB1/+JXF/wDD9f8A55yl6Akk
kkkkkkkkkkkkkkoXXVUVPuue2qqppfZY8hrWtaNz3ve72tY1q81zbc3/ABn9UGDhB2L9U+m3brs0
tiy+0At/V/UHsf6VjvSr/wABTb9pzP0tmNhrV/xefUC36r5vUcrMe2697vs+Ha2QDj+y51u3e7a+
+3067KrGfoH4n6K62m7eu4SWZdTb0y1+XiMdbhWuL8vEYC5zHOO6zNwq2+5z3O/SZuFX/Sv6Xif5
Q9ejqmhTdVfUy6l7barWh9djCHNc1w3Mex7fa5jmqaSSSSSSSSSSSSSSSSr5ubVhVB7w6yyx3p0U
VwbLbCC5tNLXFrd+1r3uc97KaaWWZGRZTj022sr4uDlWXtzeqPrtyK5ONRUCKaNwLXlpsJfk5ex7
sf7c9lH6v/R8TC+0Zn2nQSSSSSSSSSSSSSSSSSSQcrFozKHY+Q3fU+JElpBaQ+uyuxhbZVbVY1tl
N1bvVpt/S1fpFV6ZlXt29N6i7d1GisE2wGtyWN2sdnUNYGsbue5n2vG/7Q32en/RrcLKy9BJJJZP
1i/Q0YnURz07LpuJP0G12E9Pzbr/AN2rGwM7KyfU3MZT6PrXfoa7GLWSSSSSSSSSSSSWT0r9L1fr
V79ba8inEY7iKa8bHza6oHt9uT1HNs3/AM5+m/0ddWzWSSSSSSWTT/lbPx+oM/5Owt78Rx/w9z2+
h9uqj3fZKcazKox3u/R5/wBrsyWVehRg5eUbq3X+jdF+z/tXLrxPtdnpUeoT7ndz7Z2VMn9LfZ+g
p/wti0Ekkkkkkkkkkkkkkklk/Wz/AMSvWf8Awhlf+ebFwH/5if8AX/ywX//Q1f8AHX/4lcX/AMP1
/wDnnKXoCSSSSSSSSSSSSSSShddVRU+657aqqml9ljyGta1o3Pe97va1jWrzfKyupf4zOpO6f091
mH9UcOwfa8uNr8p7Ye2utrx/bppf/R/6Zmfp/smIvQ+n9Pwum4VOBgUtx8XHbtqqbwBz39znud77
LH++x/6SxWEkklmXdPdg2vzuk0tDrHF+ZhM2sbkFx3PvZOyqvqf/AHYf7Mz+jZ1n9FzOn28LNqza
i9gdXZW7076LIFlVgAc6m5rS5u/a5j2uY99N1L68jHsux7qrX2EkkkkkkkkkkkkklRzepOotGJiU
OzM1zd/otc1ja2OJZXkZlz/5jHda3b+jZflW7L/smJlfZsj01hdLqx7TmX7cnqVjdt2YWgO2kh32
bH+m7GwmOb+ixW2f8Ne/Iy7L8q68kkkkkkkkkkkkkkkkkkkkq+bhVZtQY8ursrd6lF9cCyqwAtbd
S5wc3ftc9jmvY+m6l9mPkV3Y91tTw4Wba604OcG151bd/skV3Vghv2rF3Fztm5zG5OM577sK5/p2
etRdh5mXeSSULqar6n03MbbVa0ssreA5rmuG17Hsd7XMc1Z/1dutd0tmNkPdZlYDnYeQ+wk2Pdjn
0WZVwf72Pz6G09Qa1/8Agcuv9Ld/PWaaSSSSSSSSSSr9QzasDCuzLQ57aWyK2QXvcfbVj0McW+pk
ZFpZTj1f4W6yutB6NhW4PTq6by12S91l+SWSWevkWPzMoUbg1/2duRfb9n9T9J6Pp+p71eSSSSSW
T/y5/wCmb/28/wDlV/8AFX/01f8AKuss/rvQum9f6bZ03qVfqU2atcNH1vH0L6H67LWT/wCi7N9T
7K1xXQuu9S+pPUq/qt9abPU6ZZp0jq50YGD2tovc6dlTJaz3u/yf/L6e+i+n0VJJJJJJJJJJJJJJ
JZP1s/8AEr1n/wAIZX/nmxcB/wDmJ/1/8sF//9HV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJJJJ
JKF11VFT7rntqqqaX2WPIa1rWjc973u9rWNavN8rK6l/jM6k7p/T3WYf1Rw7B9ry42vynth7a62v
H9uml/8AR/6Zmfp/smIvQ+n9Pwum4VOBgUtx8XHbtqqbwBz39znud77LH++x/wCksVhJJJJJUc3p
VWVaMmu67DzGt2Nysdwa7aCSGW1WtuxMpjN9vpfbMbI+z+tdbjejc/1FX/amV072darmoa/tPHrI
xoOv6zR6uVk9P9JvqetkX+p05lNfr259Nl32SnTpuqvqZdS9ttVrQ+uxhDmua4bmPY9vtcxzVNJJ
JJJJJJJJBysvFwqHZOZdXjY9cb7rXBjGyQxu6ywtY3c921Z/2vqXU/b09lnT8X87Nyqdtjwfa5mF
hXuruotZ7/1nqWN6TH11eng9Rx7/AFKr2FgYuBUasZrgHu32Pse+2x7iA3fdkZDrb7n7GMqb6tn8
zXXT/NVsVhJJJJJJJJJJJJJJJJJJJJJJV83Cqzagx5dXZW71KL64FlVgBa26lzg5u/a57HNex9N1
L7MfIrux7ran18XOyq724XVGV1ZFkjGvqJNN+0Fzw0WAPxsvYx2R9he+/wDV/wCj5eb9nzPs2gkk
sm3/ACV1KzMd/Qep2UsujmvLdswaL3DV9lWaz7FhO9P+i20UXej6eTm5ONrJJJJJJJJJJLJyP8o9
ZrxB7sTpm3Iye7X5Lh+o4zvp1v8Aste/qF9Nmy6i/wDYuXStZJJJJQuuqoqfdc9tVVTS+yx5DWta
0bnve93taxrVmenldY0yqvs/SXaih5IuyW/mszqXsZ9kxP8ACPwt9t+XW+qnP+yfrvTsjWSSWf13
oXTev9Ns6b1Kv1KbNWuGj63j6F9D9dlrJ/8ARdm+p9la4roXXepfUnqVf1W+tNnqdMs06R1c6MDB
7W0XudOypktZ73f5P/l9PfRfT6Kkkkkkkkkkkkkkksn62f8AiV6z/wCEMr/zzYuA/wDzE/6/+WC/
/9LV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJJJJKF11VFT7rntqqqaX2WPIa1rWjc973u9rWNav
N8rK6l/jM6k7p/T3WYf1Rw7B9ry42vynth7a62vH9uml/wDR/wCmZn6f7JiL0Pp/T8LpuFTgYFLc
fFx27aqm8Ac9/c57ne+yx/vsf+ksVhJJJJJJJJZl3SLarX5HSsp2FbY4vspeDdivc4y978Nz6nUv
3Ptu/wAn5GD6+VZ6+b9rUP2xn4+nUel5FbW/zmRiFuXSJ+h6VdXp9Wu/MY//ACT+js/7rM+0q3g9
V6b1HeMLJrvfTHr1NP6SoumK8rHdF2Nb7Ht9HIrrt3seraSSSSSSz8rr/ScW92K+/wBXLrj1MTGY
/JvYCA8WW4mEzIyaqtrmfprKvS/SVf6WtB+39dyfZi9M+xdn259tftn6NlGP02zO+1el9K2m7K6d
v/Rsrv8AfZZQbF6TsvbmZ2RZnZjJLHv9lNRcC132TCr/AENW3fdXXkW/aeo/Z7n49uffUtBJJJJJ
JJJJJJJJJJJJJJJJJJJJBysTFzaHY2ZTXk49kb6bWh7HQQ9u6uwOY7a9u5Z+7qXSdHNs6l04aMLB
uy6Gj3brzZbv6nUxm5u6iv8Aaf6On9B1XJvuyWadN1V9TLqXttqtaH12MIc1zXDcx7Ht9rmOapqF
1NV9T6bmNtqtaWWVvAc1zXDa9j2O9rmOaszpuX9kvd0fPu/WBY/9nuud78jHj12ek55c++3BZvw8
n9Ldl/q1fUMv+nVLWSSSSSSSSWf1PqfobsHBdXb1i2suxcVxmJ3MZl5bGObZV0+qxv6e/wD9B8f1
cy3Hx7bGFhVYVRYwusssd6l99kGy2wgNddc5oa3ftaxjWsYymmllePj1049NVTLCSSSo5vVasW0Y
1dN2ZmObvbi47Q520kgPtttdTiYrH7LfS+2ZOP8AaPRuqxvWuZ6aFT0u3JtZlda9HJtqcH4uOxpN
GO4He2xnrbnZObW79H+0HMx/0f8ARcTB9fL+0aaSSSSz+u9C6b1/ptnTepV+pTZq1w0fW8fQvofr
stZP/ouzfU+ytcV0LrvUvqT1Kv6rfWmz1OmWadI6udGBg9raL3OnZUyWs97v8n/y+nvovp9FSSSS
SSSSSSSSSWT9bP8AxK9Z/wDCGV/55sXAf/mJ/wBf/LBf/9PV/wAdf/iVxf8Aw/X/AOecpegJJJJJ
JJJJJJJKF11VFT7rntqqqaX2WPIa1rWjc973u9rWNavN8rK6l/jM6k7p/T3WYf1Rw7B9ry42vynt
h7a62vH9uml/9H/pmZ+n+yYi9D6f0/C6bhU4GBS3Hxcdu2qpvAHPf3Oe53vssf77H/pLFYSSSSSS
SSSSSVTO6XgdQ2HKq3W0z6N7HOqur3R6n2fLodVk4/qtbst9G1nq1/o7P0aqfsD0v6D1LPw5/nP0
/wBq3R9H/llnU/R2e7+jeh6n+G9T9F6a/Z3XaP6L1f1t30/t+NXbEfR9D9mu6Ns/4X1vtP8Ag/T9
H9J6q/7KqP8AuB1Hd/x2Dsj/ANzf2j1P/Qb0tn+G9X9EvtP1q/8AK7A/9jrv/kUlt+tV/v8AUwMC
NPS9O7Nn/hPtHq9G2fu+j9ls/f8AX/SenUv2Z1q73ZPWbKXjQNwaKKq4/eezqDOr3er/ACm5LKtn
p/oPp2Wr/m9Xb7s3Pz8u0aCz7S/Ghv7no9I/Z2M73f4R9Hr/APC+n6WzQxcTFwqG42HTXjY9c7Ka
mhjGyS922usNY3c925GSSSSSSSSSSSSSSSSSSSSSSSSSSSSSWZd0d1Vr8npFzenX2uL76/SbZj3P
cfdflYzTRa7I9z/1jGysS679D9ssyqceqlKnrlTLWYvU6ndNyrHCusWkGi15OxjcPOb+gufc/f8A
Z8W37P1KytnrP6fStNBysWjModj5Dd9T4kSWkFpD67K7GFtlVtVjW2U3Vu9Wm39LV+kWf9uyule3
q9nr4h/m+oV1EbAPzepsq9Sun9H+ns6mxuN07+f9anp3p4/2vTpuqvqZdS9ttVrQ+uxhDmua4bmP
Y9vtcxzVNJJJJJZl3WG5Fr8LpJbk5bXGu26HPx8dzTtu+1X17anZFH/lZXf9ts307/suM+zNot4W
FVhVFjC6yyx3qX32QbLbCA111zmhrd+1rGNaxjKaaWV4+PXTj01VMsJJKvm9QwsCoW5lzaWvdsrB
1c95BcyjHqbNuRkWbf0WPSyy63/B1qj6nVuqa0GzpOH2tfWx2XaD7mW0V3G6nBq+h/T8W7Ms9S6m
zD6dbTXdbewun4WBUasOltLXu32Eaue8gNffkWum3IyLNv6XIufZdb/hLFYSSSSSSWf13oXTev8A
TbOm9Sr9SmzVrho+t4+hfQ/XZayf/Rdm+p9la4roXXepfUnqVf1W+tNnqdMs06R1c6MDB7W0XudO
ypktZ73f5P8A5fT30X0+ipJJJJJJJJJJJLJ+tn/iV6z/AOEMr/zzYuA//MT/AK/+WC//1NX/AB1/
+JXF/wDD9f8A55yl6AkkkkkkkkkkkoXXVUVPuue2qqppfZY8hrWtaNz3ve72tY1q83ysrqX+MzqT
un9PdZh/VHDsH2vLja/Ke2Htrra8f26aX/0f+mZn6f7JiL0Pp/T8LpuFTgYFLcfFx27aqm8Ac9/c
57ne+yx/vsf+ksVhJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJQupqvqfT
cxttVrSyyt4Dmua4bXsex3tcxzVmfsW/F16PnWYbB9DDtaMjEB+jpTYa8yiplftoxcHqGHh0enX+
r/z1dy/bj8T29ZxLMIjnIqDsnEjl9hzKamvxaqGFnr3dTxun1fznpetTTZer2F1Hp/UKjdgZNOXU
12x1lFjbGhwAcWF9TnN37XNVS7pFtVr8jpWU7CtscX2UvBuxXucZe9+G59TqX7n23f5PyMH18qz1
837WoftfqdHtzOkZHs1tvxLKcikN+lvqD7MXqV+xn066+mev6n6PHqyP0fqr/nT0Jn9KyvsE/Q+3
12YW/wDe9D9pV4vr7P8AC+j6npfo/U/nK0v+dn1V/wDLnA/9iqf/AEol/wA6vq+/TGza85/erB3Z
lgH+kfj9Pbk3Mq/N9Z1fpb/T/wBIxL9uX36dO6Zl5APtF1zBiVtf4XM6g7Hz/Sb7XWX43T8v2fzP
r3VvoS/Z/Vc/XqmT9lpP/aLAe9k/8f1SMfNt9zWW1fY6+l7P0mPkfbalp001UVMppY2qqpoZXWwB
rWtaNrGMY32tY1qmks/K6/0bEvdi25dbsxkThVE3ZOoD/bgY3q5j/wBG71fZR/M/pv5pB+0dZ6jp
iV/szEd/2pyGh2S9p/OxsH+bxd9b/Upv6g/16Lmejl9FVjC6PhYdpyQHX5r27LM28+pe5pIe+sWO
/mMd1rfV+x4raMKqz+YxqleSSSSSSSSSWf13oXTev9Ns6b1Kv1KbNWuGj63j6F9D9dlrJ/8ARdm+
p9la4roXXepfUnqVf1W+tNnqdMs06R1c6MDB7W0XudOypktZ73f5P/l9PfRfT6Kkkkkkkkkkkksn
62f+JXrP/hDK/wDPNi4D/wDMT/r/AOWC/9XV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJKF11VFT
7rntqqqaX2WPIa1rWjc973u9rWNavN8rK6l/jM6k7p/T3WYf1Rw7B9ry42vynth7a62vH9uml/8A
R/6Zmfp/smIvQ+n9Pwum4VOBgUtx8XHbtqqbwBz39znud77LH++x/wCksVhJJJJJJJJJJJJJJJJJ
JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJUc3onSM+0X5mHTdksbtrySwC9gBLmfZ8psZGO
+t7vUqsptrfVZ+kr96r/ALJ6li/8mdTsazhuPnN+2VtB9znMtNmN1N9u/wDOyep5FTGepV6H8x6C
+2/WDG/pPTq8xg9ofg3t9Rx/0z8TqAwqcap8fzbep5ltL/Tq/WPfkJft/wBL+ndNz8Of5v8AQfat
0fS/5Gf1P0dnt/pPoep/gfU/S+mv+cvTv9Dn/wDuOzv/AHjS/wCcvTv9Dn/+47O/940v+cvTv9Dn
/wDuOzv/AHjS/wCcvTv9Dn/+47O/940v23mu91XRM+yo6ssnFr3NP0X+jlZ1GTVub/g8iim9n+Fq
rsS/7Kr/APuB07b/AMdnb5/9wn2f0/8A0J9Xf/gfS/Sr/m7i3/8AKl+R1btsy3j0S381lvT8RmL0
2/Y/9KyzIw7b/U/wv6Gj0tDFxMXCobjYdNeNj1zspqaGMbJL3ba6w1jdz3bkZJJJJJJJJJJJJZ/X
ehdN6/02zpvUq/Ups1a4aPrePoX0P12Wsn/0XZvqfZWuK6F13qX1J6lX9VvrTZ6nTLNOkdXOjAwe
1tF7nTsqZLWe93+T/wCX099F9PoqSSSSSSSSSSyfrZ/4les/+EMr/wA82LgP/wAxP+v/AJYL/9bV
/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJLzzrVPXvrz17I6A1l3S/q30u4M6hc4bbMmxsWMZVu9r
mObsuxv8Cyn0uoZHqWWYWMu76f0/C6bhU4GBS3Hxcdu2qpvAHPf3Oe53vssf77H/AKSxWEkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
ln9d6F03r/TbOm9Sr9SmzVrho+t4+hfQ/XZayf8A0XZvqfZWuK6F13qX1J6lX9VvrTZ6nTLNOkdX
OjAwe1tF7nTsqZLWe93+T/5fT30X0+ipJJJJJJJJLJ+tn/iV6z/4Qyv/ADzYuA//ADE/6/8Algv/
19X/AB1/+JXF/wDD9f8A55yl6Akkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkksf624XQc3oOUz6wFtfT62+o+86Oqc
PbXdjuhzvtG52yprGP8AW3/Z/Tu9b0n+C3/Wnre3Cxa+oXW4fR7hb0wWtaC0sdux7LKv0zXvqaP0
VV1uSzGZ+r0/oV9BdA6zR1zo2J1bHG1mVWHFmp2PB9O+nc5te/0bmWVeps/SfTWgkkkkkkksn62f
+JXrP/hDK/8APNi4D/8AMT/r/wCWC//Q1f8AHX/4lcX/AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSr5vTun9QqFOfjU5dTXb2131tsaHAFoeGWtc3ftc5eefWP/ABMYGRN/1dv+xW6fqmQXPpP0G+y/
9Jk0+31bHep9r9Sz/QVoX+LF/Wfq11a76rddxbMQZ+7IwS4AsddWxjsllN9LbKr9+L6b7HfafTx/
s3pfz169QSSSSSSSWT9bP/Er1n/whlf+ebFwH/5if9f/ACwX/9HV/wAdf/iVxf8Aw/X/AOecpegJ
Ll/qx9WPq3f9W+k3XdJwrbbcLHfZY/Hqc5znVVue973V7nPc5aX/ADT+qv8A5TYH/sLT/wCk0v8A
mn9Vf/KbA/8AYWn/ANJpf80/qr/5TYH/ALC0/wDpNL/mn9Vf/KbA/wDYWn/0ml/zT+qv/lNgf+wt
P/pNL/mn9Vf/ACmwP/YWn/0ml/zT+qv/AJTYH/sLT/6TS/5p/VX/AMpsD/2Fp/8ASaX/ADT+qv8A
5TYH/sLT/wCk0v8Amn9Vf/KbA/8AYWn/ANJpf80/qr/5TYH/ALC0/wDpNL/mn9Vf/KbA/wDYWn/0
ml/zT+qv/lNgf+wtP/pNL/mn9Vf/ACmwP/YWn/0ml/zT+qv/AJTYH/sLT/6TS/5p/VX/AMpsD/2F
p/8ASaX/ADT+qv8A5TYH/sLT/wCk0v8Amn9Vf/KbA/8AYWn/ANJpf80/qr/5TYH/ALC0/wDpNL/m
n9Vf/KbA/wDYWn/0ml/zT+qv/lNgf+wtP/pNL/mn9Vf/ACmwP/YWn/0ml/zT+qv/AJTYH/sLT/6T
S/5p/VX/AMpsD/2Fp/8ASaX/ADT+qv8A5TYH/sLT/wCk0v8Amn9Vf/KbA/8AYWn/ANJpf80/qr/5
TYH/ALC0/wDpNL/mn9Vf/KbA/wDYWn/0ms36z/Vj6t0fVvq11PScKq2rCyH12Mx6mua5tVjmPY9t
e5r2uXUJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJLJ+tn/iV6z/4Qyv8AzzYl/wA0
/qr/AOU2B/7C0/8ApNL/AJp/VX/ymwP/AGFp/wDSaX/NP6q/+U2B/wCwtP8A6TS/5p/VX/ymwP8A
2Fp/9Jpf80/qr/5TYH/sLT/6TS/5p/VX/wApsD/2Fp/9Jpf80/qr/wCU2B/7C0/+k0v+af1V/wDK
bA/9haf/AEml/wA0/qr/AOU2B/7C0/8ApNL/AJp/VX/ymwP/AGFp/wDSaX/NP6q/+U2B/wCwtP8A
6TS/5p/VX/ymwP8A2Fp/9Jpf80/qr/5TYH/sLT/6TS/5p/VX/wApsD/2Fp/9Jpf80/qr/wCU2B/7
C0/+k0v+af1V/wDKbA/9haf/AEml/wA0/qr/AOU2B/7C0/8ApNL/AJp/VX/ymwP/AGFp/wDSaX/N
P6q/+U2B/wCwtP8A6TS/5p/VX/ymwP8A2Fp/9Jpf80/qr/5TYH/sLT/6TS/5p/VX/wApsD/2Fp/9
Jpf80/qr/wCU2B/7C0/+k0v+af1V/wDKbA/9haf/AEml/wA0/qr/AOU2B/7C0/8ApNL/AJp/VX/y
mwP/AGFp/wDSaX/NP6q/+U2B/wCwtP8A6TS/5p/VX/ymwP8A2Fp/9Jpf80/qr/5TYH/sLT/6TVLM
6H0Xp/Vuh3YHT8bEtdm2MdZRTXW4tOF1BxYX1Ma7Zua1dGsn62f+JXrP/hDK/wDPNi4D/wDMT/r/
AOWC/9LV/wAdf/iVxf8Aw/X/AOecpegJLJ+qf/iV6N/4Qxf/ADzWtZJJJJZ/7e6Z9q+y77N3qej6
3o3fZ/Un0vR/aHpfYfV9f9W9P7Tv+1/qn9J/RJO690wZ7+nNfZbl1WMqurqput9N1ja7ajkvoqsr
x6rK7m7L7310fz36T9XyPSr0/W3oV9TMim26zFsaHjLbjZBxw0jc59ub6H2SllP/AGp9W5n2TZaz
K9H0bVazesYODaKbvWstLd5rx6LslzWklrH2swqsh1LLHMs9L1tnreld6X8zahZvWGt6bTn4Jba2
7Jxcf3hwgXZVOBkMfWfTtqyKPVtZ6VvvoyK/Tvq9npoub1jBwbRTd61lpbvNePRdkua0ktY+1mFV
kOpZY5lnpets9b0rvS/mbVVwfrBVd0V3VbC26s5N2Pj/AGeHC2Muzp2A2lzn+lvyv1f9K+2vH32+
rvpoVfIszPtVdGf1mzByr9u3GwKa3U1iw7KGZWVnYud+luu342Nk3P6dV1Cyv0sXB+0eqxWOk9Rc
63GxXZDs+jPxnZ2Bmva1ljqmmj1GZVVdePVv/Xcd+NZVRVvp/Q30VXY32jNsYvXumZd7aKH2TbPo
WPpurptgF/6pl3VV4uXuqa++v7Ndb6uOx+RV+hZ6iWV17pmJe6i99k1R69jKbrKapAf+t5dNVmLi
banMvs+03VeljvZkW/oX+orGbn4uBULclzgHu2VsrY+2x7iC7ZTj47bb7n7GPtd6Vf8AM12XfzVb
0sLPxc+o24znEMdssZYx9VjHAB2y7HyG1X0v2PZa31a/5myu7+asYlm5+LgVC3Jc4B7tlbK2Ptse
4gu2U4+O22+5+xj7XelX/M12XfzVb0sLPxc+o24znEMdssZYx9VjHAB2y7HyG1X0v2PZa31a/wCZ
sru/mrGKpT9YulXWsrY+7ba4NqyHY97cd5cdtPpZ9lLcGxmQ4sZjWMyNmV6lX2f1PVrSv+sXSqMq
7EL7rsnGcG5FWPj35Dqy5jL6/VbiU3+my2q39FY/2W/pvT99F/pqn6x9HvtZXTc62u1wZXlMqtdi
uc47GMZ1Ntf7Pc91v6v/AEn+lfqv9I/RLTSSSSWT9bP/ABK9Z/8ACGV/55sWskkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkksn62f8AiV6z/wCEMr/zzYtZJJJJZ+V17pmJe6i99k1R69jK
brKapAf+t5dNVmLibanMvs+03VeljvZkW/oX+oq+J9YsVvQuldT6o9tFnU6aS1rGvcHX20/a/s9F
bPWtc9/p2Nx6v5y5/p0V+pfZWrFnXen1UU3vGR+sbvSpGNkG8hh2WWOwW0HNZUxxZuusx/S/S0f6
eneX9qYH2D9oer+rcTtdv37vR+z+ht+0fa/tH6t9j9L7V9q/VvR+0fo0LD690zNyhhUvsblmt132
e+m6iz02Gut13pZdVNnpepcxldn0Ln+r6X9Hv9OF31i6VTa+t77ttTi23Ibj3ux2Fp23ern10uwa
2Y7g9mTY/I2Yvp2/aPT9KxTzOvdMwso4Vz7HZYrbd9nopuvs9N5srbd6WJVdZ6XqUvZZZ9Cl/per
/SKPUk3rPTndPyOomxzMbEa92T6ldldlYrb61nrYtrGZVb/R/TNrfTvspfXbX7La1m52VmN2XdS6
lZ0ZlsupxcWqu2xlbY9W7qWRfT1Kn0qN1TsjJpqxMDp77/RvzMz9XyUXCzrMa/HqdmWdTxc7IuxK
77WMZdXk44yHX1OGPTiU24n6hks3+j61WRX/ANq8fK/UodD+teD1Dp/T7bnObfl00myxlFwxRfY1
m/HZnurdhb/tLvsvpfa/U+1fqf8ASv0aNk/WGnD61f0/J3FrMbHyKWUU233uNtmZVkPNOIy+37PV
9mxv0vo7KrL/ANLb+npUup9doxukM6rRZX9nORj1WWXSxrGWZNOFl+sH+k/HtxmWXeoy/Z9mvq/W
K/0dlasYXWMHOtNNPrV2hu8V5FF2M5zQQ176mZtWO65lbn1+r6O/0fVp9X+eqV5Z+L17pmXe2ih9
k2z6Fj6bq6bYBf8AqmXdVXi5e6pr76/s11vq47H5FX6FnqKWb1jBwbRTd61lpbvNePRdkua0ktY+
1mFVkOpZY5lnpets9b0rvS/mbVG7r/SaMWjLtv205Vhpo9jy91wFjzi+g1nrNy/1e6n7K+v7R9q/
U/T+1foUH/nP0j6O7I9bn7L9lyftOz/uR9g+z/bfsm79H9s9D7L636H1vVWhi5VGZQ3Ix3b6nzBg
tILSWWV2VvDbKrarGurupsb6tNv6K39IjJJJLJ6z/wAo9C/8Pv8A/bHqS1lk/Wz/AMSvWf8Awhlf
+ebFwH/5if8AX/ywX//T1f8AHX/4lcX/AMP1/wDnnKXoCSyfqn/4lejf+EMX/wA81rWSSSSXCdWy
G39AzMIdUsxOpPxLaWfVjErx3Ord6bq6+n1YgxL+pW1NZt35dFnoXUf5RxPsuB6Xo9H0C6q/M61d
S9ttVubU+uxhDmua7A6a5j2Pb7XMc1Zn/wCaz/2g/wDumrtXUen9H6l1UdVyacAZuSzIxXZFjam2
VjFw8R7qrLXNY99d+Lay2r+ep/Q2Ws9LIx/VpZH6XDzs6v3Yud1rpt2Lb2srbZ0fE9av/gn3Y13o
2fQvq/WKPUx7abX3auo9P6P1Lqo6rk04AzclmRiuyLG1NsrGLh4j3VWWuax7678W1ltX89T+hstZ
6WRj+rS6cH3dMwup012WU4XV+o5VtQY4Xek+7quJ7MV7W3erV9sZdZjbPtPp1211U25Xp41qpqzO
pdMzMHDrrysfqGRkXXdUF1bsbJofc/8AUmX478jN9V2F6PRbLXY1X7PpqtsxbrfsWHTk2w89Qv6h
l241d+Xi4jsarolltLrWi4evazP9F9+NT+13U4tdddrsiqvGxfX9T9ayserK6ln411NDh9YLM26v
Lw78vAYyhrKWVZOPkZduXjsxj1LpmJgsre+z9oZn6r6bKMzIst/nbt2bRVkX05XV3dCubdZ6HTMd
uNvta57315VNWTi5mR1DI6k97sj9Rb/PW/YPRs6hjZVlosK8Y31e6D6tzem1VYTcfL6qRWX41lbK
K7OnudlMtpw335VDq8mzLr9Gu7B+wen9vycN9Muk9RwsbqvVc+3qdnUMNuBRa3OtbWWuZjPzrM37
G/Ax8anNqwvtNH2h+MzI9G/I+z22er+hWn1S6rC61g9TzHtowasbKx7cmwhtbLLrMG2ht1jvbSy1
uJe1ttv6H1vTo3+vkY9doepPx+udF6w3pFbcqzJwrMarMr2ene813tqx6crd+mZj23e6z+i1XZFl
XrevXmV0C651vpHU+i9Q6XgZlN/Us3Gux6MFrx9oNtlb6m024joyMd9b3frP2iur7H+lsy/QrptV
3o3/ACj13/w+z/2x6asqj/xCdA/9ov8A7cdPXVpJJJLJ+tn/AIles/8AhDK/882LWSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSWT9bP8AxK9Z/wDCGV/55sWskkkkuf6b1XpvSKb8DqWT
XjZv2vMtZivP6axmRk5GXiuxKGzbmevVfX6f2Rl36xvxP6XVbSqnTP8Akf6k/wDWf/iXmq71rJrx
+ofrOa3oeNZSyOpgUB1z2utjBdkZ1V+PSzFY92Qymyv1sv7VY/E9NmFn+tldNa52Tfm1X3dRrwuq
tznWOY0X3YtnTv2WzMxqMenGZlY/rm70LcWj9dx8K/7F9syPZfp09Rrz/rVhOppyK6mYGaPUyKX4
+5xu6ZuYynLbTk/o27N1noeh+l/RW2WMv9GHQ+t9I6Z0Xp/S8/Mpo6lhY1OPfguePtAtrrZU6mrE
bORkPse39W+z12/bP0VmJ69d1Sh9VcW/Cym4eS308jG6L0qq5kg7XsPUq7G7mFzHbXt/NSsxb8o9
dZjt9S2rq+FkiuQC8Y1PR82yqsvLa/Vtrx3V0+o+ur1f522qv9Ilj5OZlZPVHdJHrPz7Gsp6mHVl
uEGUU1fZc3GyHjOry8LJ+15jOmfY/S9fM/WLMX7TmWUG6dUx+fg4F1deAOjY5OL003NtscQ37AzP
q2P+0fs/Hx3ZGJj25X6XLfl2fasPEuxcf1crE6r03N+oNPRcbJrs6rk9Ibi04ExkOtfjCmv9Vftu
bU7d6v2lzPs32T9e9b7H+nWrd1XpvTfrVmnqGTXiMtwMLZbefTrJbd1P9H9os20ttdu3V0us9W1j
LfS/mbtlLOtaOndR6mA5+HldY6dkY1jGuebaq7Oj4zrqKqw+65j7sW77P6df60z07sb1abqbLL9v
Uen9Y6l0odKyac8YWS/IynY9jbW11nFzMRjrbKnOYx9l+VUyqr+eu/TWVM9LHyPSsdb/AMqdE610
7B/TZbce7ENf0f01uOLaqt9myv315VHv3+n70h13oee+vEosrz8h1jC7DZtddUWObZ6+XjW7LML7
FYz1LPtTabachjKGfr32fHsr1dR6f0fqXVR1XJpwBm5LMjFdkWNqbZWMXDxHuqstc1j3134trLav
56n9DZaz0sjH9WlX+l6vi51fuxc7rTrsW3tZW3pFuJ61f/BPuxrvRs+hfV+sUepj202v1cb/AMVX
Uf8Awhg/+fuqpfVr/k67/wAP9R/9vsxaySSSyes/8o9C/wDD7/8A2x6ktZZP1s/8SvWf/CGV/wCe
bFwH/wCYn/X/AMsF/9TV/wAdf/iVxf8Aw/X/AOecpegJLJ+qf/iV6N/4Qxf/ADzWtZJJJJJJJJJJ
JZ+V9XugZt7snM6ZiZORZG+62it73QAxu6yxjnu2sbtVrFxMXCobjYdNeNj1zspqaGMbJL3ba6w1
jdz3bkZJJJJJJJJJJJJJZP1s/wDEr1n/AMIZX/nmxaySSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSyfrZ/4les/wDhDK/882LWSSSSSSSVfNwMXPqFWS1xDHb631vfVYxwBbvpyMd1V9L9
j31O9Kz+Zssp/mrHqGD0vDwN5xxY59sb7b7bL7CGz6df2jLsvu9KvfY6un1PSrfbb/pbFbSSVHN6
H0XqFouz+n42Xa1uxtl9Ndjg0EuDA+1jnbNznI2F07p/T6jTgY1OJU5291dFba2lxAaXllTWt37W
tVhJJJJJJJJJJJJJZPWf+Uehf+H3/wDtj1JayyfrZ/4les/+EMr/AM82LgP/AMxP+v8A5YL/1dX/
AB1/+JXF/wDD9f8A55yl6Akuc6HmdW6f0Xp+Bd0PNdbiY1NFjmWYRaXV1sqeWF3UGu2bm/uq7+2e
o/8AlFn/AOfg/wDySS/bPUf/ACiz/wDPwf8A5JJftnqP/lFn/wCfg/8AySS/bPUf/KLP/wA/B/8A
kkl+2eo/+UWf/n4P/wAkkv2z1H/yiz/8/B/+SSX7Z6j/AOUWf/n4P/ySS/bPUf8Ayiz/APPwf/kk
l+2eo/8AlFn/AOfg/wDySS/bPUf/ACiz/wDPwf8A5JJftnqP/lFn/wCfg/8AySS/bPUf/KLP/wA/
B/8Akkl+2eo/+UWf/n4P/wAkkv2z1H/yiz/8/B/+SSX7Z6j/AOUWf/n4P/ySS/bPUf8Ayiz/APPw
f/kkl+2eo/8AlFn/AOfg/wDySS/bPUf/ACiz/wDPwf8A5JJftnqP/lFn/wCfg/8AySS/bPUf/KLP
/wA/B/8Akkl+2eo/+UWf/n4P/wAkkv2z1H/yiz/8/B/+SSX7Z6j/AOUWf/n4P/ySS/bPUf8Ayiz/
APPwf/kkl+2eo/8AlFn/AOfg/wDySS/bPUf/ACiz/wDPwf8A5JJftnqP/lFn/wCfg/8AySS/bPUf
/KLP/wA/B/8AkkqXXMzq3UOi9QwKeh5rbcvGuorc+zCDQ6yt9TC8t6g52zc791dGkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkks/6w4t+b0DqeHjN9TIycS+qlkgbnvrfXW3c8tY3c935y
D+2eo/8AlFn/AOfg/wDySS/bPUf/ACiz/wDPwf8A5JJftnqP/lFn/wCfg/8AySS/bPUf/KLP/wA/
B/8Akkl+2eo/+UWf/n4P/wAkkv2z1H/yiz/8/B/+SSX7Z6j/AOUWf/n4P/ySS/bPUf8Ayiz/APPw
f/kkl+2eo/8AlFn/AOfg/wDySS/bPUf/ACiz/wDPwf8A5JJftnqP/lFn/wCfg/8AySS/bPUf/KLP
/wA/B/8Akkl+2eo/+UWf/n4P/wAkkv2z1H/yiz/8/B/+SSX7Z6j/AOUWf/n4P/ySS/bPUf8Ayiz/
APPwf/kkl+2eo/8AlFn/AOfg/wDySS/bPUf/ACiz/wDPwf8A5JJftnqP/lFn/wCfg/8AySS/bPUf
/KLP/wA/B/8Akkl+2eo/+UWf/n4P/wAkkv2z1H/yiz/8/B/+SSX7Z6j/AOUWf/n4P/ySS/bPUf8A
yiz/APPwf/kkl+2eo/8AlFn/AOfg/wDySS/bPUf/ACiz/wDPwf8A5JJftnqP/lFn/wCfg/8AySS/
bPUf/KLP/wA/B/8Akkl+2eo/+UWf/n4P/wAklXtt6l1DqXSielZOJViZL77rr34paGnFzMVoDcXM
ybnPddk1f4JbyyfrZ/4les/+EMr/AM82LgP/AMxP+v8A5YL/1tX/AB1/+JXF/wDD9f8A55yl6Akk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkksn62f+JXrP/hDK/wDPNi4D/wDMT/r/AOWC/9fV/wAdf/iV
xf8Aw/X/AOecpegJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ
JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJLJ+tn/iV6z/4Qyv8AzzYuA/8AzE/6
/wDlgv/Q1f8AHX/4lcX/AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSyfrZ/4les/+
EMr/AM82LgP/AMxP+v8A5YL/0dX/AB1/+JXF/wDD9f8A55yl6Akkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkksn62f+JXrP/hDK/wDPNi4D/wDMT/r/AOWC/9Lr/wDGB0XpXWuhsxOp9Rr6SxuQyyjKtLAz
1A2xvpubc+n1N9L7vYy2t/8AhP8AB7Fi/wDjcfWr/wCfTP8Auu/970v/ABuPrV/8+mf913/vel/4
3H1q/wDn0z/uu/8Ae9L/AMbj61f/AD6Z/wB13/vel/43H1q/+fTP+67/AN70v/G4+tX/AM+mf913
/vel/wCNx9av/n0z/uu/970v/G4+tX/z6Z/3Xf8Avel/43H1q/8An0z/ALrv/e9L/wAbj61f/Ppn
/dd/73pf+Nx9av8A59M/7rv/AHvS/wDG4+tX/wA+mf8Add/73pf+Nx9av/n0z/uu/wDe9L/xuPrV
/wDPpn/dd/73pf8AjcfWr/59M/7rv/e9L/xuPrV/8+mf913/AL3pf+Nx9av/AJ9M/wC67/3vS/8A
G4+tX/z6Z/3Xf+96X/jcfWr/AOfTP+67/wB70v8AxuPrV/8APpn/AHXf+96X/jcfWr/59M/7rv8A
3vS/8bj61f8Az6Z/3Xf+96X/AI3H1q/+fTP+67/3vS/8bj61f/Ppn/dd/wC96X/jcfWr/wCfTP8A
uu/970v/ABuPrV/8+mf913/vel/43H1q/wDn0z/uu/8Ae9L/AMbj61f/AD6Z/wB13/vel/43H1q/
+fTP+67/AN70v/G4+tX/AM+mf913/vel/wCNx9av/n0z/uu/970v/G4+tX/z6Z/3Xf8Avel/43H1
q/8An0z/ALrv/e9L/wAbj61f/Ppn/dd/73pf+Nx9av8A59M/7rv/AHvS/wDG4+tX/wA+mf8Add/7
3pf+Nx9av/n0z/uu/wDe9L/xuPrV/wDPpn/dd/73pf8AjcfWr/59M/7rv/e9L/xuPrV/8+mf913/
AL3pf+Nx9av/AJ9M/wC67/3vS/8AG4+tX/z6Z/3Xf+96X/jcfWr/AOfTP+67/wB70v8AxuPrV/8A
Ppn/AHXf+96X/jcfWr/59M/7rv8A3vS/8bj61f8Az6Z/3Xf+96X/AI3H1q/+fTP+67/3vS/8bj61
f/Ppn/dd/wC96X/jcfWr/wCfTP8Auu/970v/ABuPrV/8+mf913/vel/43H1q/wDn0z/uu/8Ae9L/
AMbj61f/AD6Z/wB13/vel/43H1q/+fTP+67/AN70v/G4+tX/AM+mf913/vel/wCNx9av/n0z/uu/
970v/G4+tX/z6Z/3Xf8Avel/43H1q/8An0z/ALrv/e9L/wAbj61f/Ppn/dd/73pf+Nx9av8A59M/
7rv/AHvS/wDG4+tX/wA+mf8Add/73pf+Nx9av/n0z/uu/wDe9L/xuPrV/wDPpn/dd/73pf8AjcfW
r/59M/7rv/e9L/xuPrV/8+mf913/AL3pf+Nx9av/AJ9M/wC67/3vS/8AG4+tX/z6Z/3Xf+96X/jc
fWr/AOfTP+67/wB70v8AxuPrV/8APpn/AHXf+96X/jcfWr/59M/7rv8A3vS/8bj61f8Az6Z/3Xf+
96X/AI3H1q/+fTP+67/3vS/8bj61f/Ppn/dd/wC96X/jcfWr/wCfTP8Auu/970v/ABuPrV/8+mf9
13/vel/43H1q/wDn0z/uu/8Ae9L/AMbj61f/AD6Z/wB13/vel/43H1q/+fTP+67/AN70v/G4+tX/
AM+mf913/vel/wCNx9av/n0z/uu/970v/G4+tX/z6Z/3Xf8Avel/43H1q/8An0z/ALrv/e9L/wAb
j61f/Ppn/dd/73pf+Nx9av8A59M/7rv/AHvS/wDG4+tX/wA+mf8Add/73pf+Nx9av/n0z/uu/wDe
9L/xuPrV/wDPpn/dd/73pf8AjcfWr/59M/7rv/e9L/xuPrV/8+mf913/AL3pf+Nx9av/AJ9M/wC6
7/3vS/8AG4+tX/z6Z/3Xf+96X/jcfWr/AOfTP+67/wB70v8AxuPrV/8APpn/AHXf+96X/jcfWr/5
9M/7rv8A3vS/8bj61f8Az6Z/3Xf+96X/AI3H1q/+fTP+67/3vS/8bj61f/Ppn/dd/wC96X/jcfWr
/wCfTP8Auu/970v/ABuPrV/8+mf913/vel/43H1q/wDn0z/uu/8Ae9L/AMbj61f/AD6Z/wB13/ve
l/43H1q/+fTP+67/AN70v/G4+tX/AM+mf913/vel/wCNx9av/n0z/uu/970v/G4+tX/z6Z/3Xf8A
vel/43H1q/8An0z/ALrv/e9L/wAbj61f/Ppn/dd/73pf+Nx9av8A59M/7rv/AHvS/wDG4+tX/wA+
mf8Add/73pf+Nx9av/n0z/uu/wDe9Cy/8XHX/st32366Zf2T03faPWFnp+nB9X1vUz/T9L0/5zf7
Ni1f+b3QP/G6/Yf7Wr/Zfpx+1t9fp+p6/r+pv3eh6X279H6Prb9n6v6/rfpl/9k=

------=_NextPart_000_0009_01C08AAB.756B7070--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Mon Jan 29 21:15:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13955
	for <sip-archive@odin.ietf.org>; Mon, 29 Jan 2001 21:15:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B03DF44337; Mon, 29 Jan 2001 20:16:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj_ntserver3.sj.nuera.com (h-207-20-110-62.ncal.verio.net [207.20.110.62])
	by lists.bell-labs.com (Postfix) with ESMTP id 554D744336
	for <sip@lists.bell-labs.com>; Mon, 29 Jan 2001 20:15:37 -0500 (EST)
Received: by sj_ntserver3.sj.nuera.com with Internet Mail Service (5.5.2650.21)
	id <D8HANGS0>; Mon, 29 Jan 2001 18:14:34 -0800
Message-ID: <DD70FD1C981BD411B64400508BA547C1049E38@sj_ntserver3.sj.nuera.com>
From: "Emami-Nouri, Mohsen" <memami@nuera.com>
To: sip@lists.bell-labs.com
Subject: RE: [SIP] Are there a few proxys in the same domain? In that case
	.......
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C08A62.62B5E5D0"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Mon, 29 Jan 2001 18:14:33 -0800

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_01C08A62.62B5E5D0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C08A62.62B5E5D0"


------_=_NextPart_001_01C08A62.62B5E5D0
Content-Type: text/plain;
	charset="KS_C_5601-1987"
Content-Transfer-Encoding: quoted-printable

A proxy server (like sip.aaa.com) should be able to find out the next =
hub
based on the request URI in this case dragon@bbb.com
<mailto:dragon@bbb.com> . Now, how the Proxy does this job is an
implementation issue (pre configured, DB lookup, etc ...). Since all 3
proxies, sip1.bbb.com, sip2.bbb.com and sip3.bbb.com represent the same
domain, it should not matter which one would get the request handed out
from sip.aaa.com.

[Emami-Nouri, Mohsen]=20
=20
 -----Original Message-----
From: hee7816@channeli.net [mailto:hee7816@channeli.net]
Sent: Monday, January 29, 2001 5:58 PM
To: sip@lists.bell-labs.com
Subject: [SIP] Are there a few proxys in the same domain? In that
case.......



=20
<http://webmail.channeli.net/webmail/button.php3?id=3Dduhetfolnaplvwzvjs=
m&user
=3Dhee7816>=20

=20
=20
In that case,
"dragon" registered at "bbb.com" domain.=20
So arnold sends a request(INVITE) to proxy 1 with request URI would be =
"
sip:dragon@bbb.com <mailto:sip:dragon@bbb.com> ".
=20
How does the proxy 1 search the next proxy server in
them(proxy2,proxy3,proxy4) ?
=20
=20
=20
=20


-----------------------------------
=A2=AC=A9=AA=A2=AC=A1=ED=A2=AC=A2=E7=A2=A5A AIAI=A9=F8YA=A2=B4=A9=F8I,
A=A2=B4=A9=F8I=A8=FA=A8=A1AI http://www.channeli.net =
<http://www.channeli.net>=20



------_=_NextPart_001_01C08A62.62B5E5D0
Content-Type: text/html;
	charset="KS_C_5601-1987"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DKS_C_5601-1987">
<TITLE></TITLE>

<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT size=3D2><SPAN class=3D819530602-30012001>A proxy server =
(like=20
sip.aaa.com) should be able to find out the next hub based on the =
request URI in=20
this case <A href=3D"mailto:dragon@bbb.com">dragon@bbb.com</A>. Now, =
how the Proxy=20
does this job is an implementation issue (pre configured, DB lookup, =
etc ...).=20
Since all 3 proxies, sip1.bbb.com, sip2.bbb.com and sip3.bbb.com =
represent the=20
same domain, it should not matter which one would get the request =
handed out=20
from sip.aaa.com.</SPAN></FONT></DIV>
<DIV><SPAN class=3D819530602-30012001></SPAN><FONT =
face=3DTahoma><BR><FONT=20
size=3D2><SPAN class=3D819530602-30012001><FONT color=3D#0000ff=20
face=3DArial>[Emami-Nouri, =
Mohsen]&nbsp;</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20
class=3D819530602-30012001></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DTahoma><FONT size=3D2><SPAN=20
class=3D819530602-30012001>&nbsp;</SPAN>-----Original =
Message-----<BR><B>From:</B>=20
hee7816@channeli.net [mailto:hee7816@channeli.net]<BR><B>Sent:</B> =
Monday,=20
January 29, 2001 5:58 PM<BR><B>To:</B>=20
sip@lists.bell-labs.com<BR><B>Subject:</B> [SIP] Are there a few proxys =
in the=20
same domain? In that case.......<BR><BR></DIV></FONT>
<BLOCKQUOTE></FONT><IMG height=3D1=20
  =
src=3D"http://webmail.channeli.net/webmail/button.php3?id=3Dduhetfolnapl=
vwzvjsm&amp;user=3Dhee7816"=20
  width=3D1 NOSEND=3D"1"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 =
Transitional//EN">
  <META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
  <DIV><IMG align=3Dbaseline alt=3D"" border=3D0 hspace=3D0=20
  src=3D"cid:819530602@30012001-2637"></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT size=3D2>In that case,</FONT></DIV>
  <DIV><FONT size=3D2>"dragon" registered at "bbb.com" domain. =
</FONT></DIV>
  <DIV><FONT size=3D2>So arnold sends a request(INVITE) to proxy 1 with =
request=20
  URI would be "<A=20
  =
href=3D"mailto:sip:dragon@bbb.com">sip:dragon@bbb.com</A>".</FONT></DIV>=

  <DIV>&nbsp;</DIV>
  <DIV><FONT size=3D2>How does the proxy 1 search the next proxy server =
in=20
  them(proxy2,proxy3,proxy4) ?</FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>&nbsp;</DIV>
  =
<DIV>&nbsp;</DIV><BR><BR>-----------------------------------<BR>=A2=AC=A9=
=AA=A2=AC=A1=ED=A2=AC=A2=E7=A2=A5&Acirc;=20
  =
&Agrave;&Icirc;&Aring;&Iacute;=A9=F8&Yacute;&Atilde;=A2=B4=A9=F8&Icirc;,=
<BR>&Atilde;=A2=B4=A9=F8&Icirc;=A8=FA=A8=A1&Agrave;&Igrave; <A=20
  =
href=3D"http://www.channeli.net">http://www.channeli.net</A><BR></BLOCKQ=
UOTE></BODY></HTML>

------_=_NextPart_001_01C08A62.62B5E5D0--

------_=_NextPart_000_01C08A62.62B5E5D0
Content-Type: image/jpeg;
	name="quest_graphic.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="quest_graphic.jpg"
Content-ID: <819530602@30012001-2637>
Content-Transfer-Encoding: base64

/9j/4AAQSkZJRgABAgEASABIAAD/7Qj6UGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAAR/+0AAIA
AgBH/7QAAgACOEJJTQQNAAAAAAAEAAAAeDhCSU0D8wAAAAAACAAAAAAAAAAAOEJJTQQKAAAAAAAB
AAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP0AAAAAAASADUAAAABAC0AAAAGAAAAAAABOEJJ
TQP3AAAAAAAcAAD/////////////////////////////A+gAADhCSU0EAAAAAAAAAgABOEJJTQQC
AAAAAAAEAAAAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBBQAAAAAAAQAAAACOEJJ
TQQMAAAAAAfVAAAAAQAAAHAAAAA0AAABUAAAREAAAAe5ABgAAf/Y/+AAEEpGSUYAAQIBAEgASAAA
/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwR
DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwR
EQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgANABwAwEiAAIRAQMRAf/d
AAQAB//EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAAAQAC
AwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVSwWIz
NHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSltcXV
5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFRYXEi
EwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOEw9N1
4/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A9EwM
DCtwqLbaK32Pra573NBc5xG5znOd7nOc5H/ZfTv+41X+YEPCtNXS8Vwbu/RtkCSY2zo1jXvd/mov
2t2wP9MwXBv0LZk/yfR3bf5f0ElLfsvp3/car/MCX7L6d/3Gq/zAotzy4e2t3eNzLWD2+LrKWtZ/
aVj1XO/mm7h+84wD/V+k5ySkP7L6d/3Gq/zAl+y+nf8Acar/ADAjbrhqWAjwa7X/AKTW/wDVKTHt
eJb8CDoQfNJTX/ZfTv8AuNV/mBL9l9O/7jVf5gVpQtsFVZeRMcDxPgkprP6f0tkbseoTwNgJPwbC
j9gwDxgsI8drB+Uqw2lx91jjvPO3T8fpJy91P0yXtP0TpM/udvpfmJKa4wemTD8WthOg3MbH+cJY
qd2LhVuIGMx2hcT7xHue3itjme3b+9/mLUNTnj3vMn81vA/8n/bVf7Kz1RXbDgQTW4sYToS7Zqz8
3d7UlNG/HwarLGDGr9hbtn1NQefot/6jelfi4rKrX10NqfUWFjml8gzz7wz6MfmrTdhVOJc6HOdG
4ljCTHE+xV8/GZXh3OaY0BMNaJgwN21oSU//0PSunMY/puKHtDgK2ESJ12o/oU/uN+4IPS/+Tsb/
AIpn5FaSUgsopc9texsGXO0GoEe3/OcpvvoY7Y+xrXbd20kA7R+d/VQ7MihmZVSbG+u9jiKpG/ZL
Qbdn0vTbZsr3/v21oxYxxlzQTESR2SUj+14m0O9avadAdwgk/NSs9r22DuQ13mD9H/NcpCuscNA+
ACHkN9UCkOLC7Uubo5oBncJn872pKTIN4c5zWt1IDnNH8ppbtQf2e7/uXkf5zf8A0mo0YRw7rck5
N+QLnNLmXODm1tDRWfQa1jPTa5zW22pKSjH9Qbm5Fv0y+JAif8ERt+gz91M+pw9rXvtc1wsO4gxt
4rH0fpomQ2sDdt9503ASdBuP0fc72t+ggMtwoAFVuo3BxptB/wA70/a5JSRmLS4B7bLSNxcP0r+S
fou930f+DeomtrA4sLnNq9xLnFx3S121peXfmsU6m1WySCdAZcC1xBlobY121zvo/ntU3geypojU
HTgBp3f+YpKSqr1P+gXfAflCtKr1P+gXfAflCSn/0fS+l/8AJ2N/xTPyKWVlegGsrZ6uRbIppBiY
+k+x8O9Kiuf0tv8A236t9lNNtfAcRh44Lntb6FcbWyJg7tdjlI25msARJ2yX8a7d36v/AFElJMbB
ZU5110XZdo23XloBLf8AQ1t93pYzP8HRu/4Sz1b7LrrDbbWfQIc391/P+eqrLc3h4HHILuY/d+zf
9/RK32EfpXOa6dAwFwj4upakpN+nOkNZ5yXfhDFJjAyeS48uPJTUlxqYXyXFokkQZjuPappKUkkk
kpA+t7QAzVoMtHdpHhxuYl9p7OqsB7w0kf5yOh3FwrJbIMjUCTEjd+9+akpgx1hJc1svdy4y1oA4
b7ve7/NUcjFssYHVWmvJYdzLNS0n/R21SPUod/o/+uVv9f8ATKNr7hHouL+ZDwW/1Y20PQzbnSID
YnUEu4n/AIj6SSk+Jl+uHMe30siqBdSTO0n6L2O9vqU2R+it/wDPd1dtVcep/wBAu+A/KFWfjmzK
ozHs/WaGvY2wOsG1lm3169raWsuY/wBKp2278+v1FPPcTi2gOe5uwzubAnczb+Y1JT//0u8xP239
lq+zeh6G0ej6k79n+D9TZ7PU2fT2o3/ZH/3V/wCmvmhJJT9L/wDZH/3V/wCml/2R/wDdX/pr5oSS
U/S//ZH/AN1f+ml/2R/91f8Apr5oSSU/S/8A2R/91f8Appf9kf8A3V/6a+aEklP0v/2R/wDdX/pp
f9kf/dX/AKa+aEklP0v/ANkf/dX/AKaX/ZH/AN1f+mvmhJJT9L/9kf8A3V/6aDl/tr0HfavQ9CW+
r6c79u5u/wBPf7N+1fNySSn/2QA4QklNBAYAAAAAAAcAAQAAAAEBAP/iAaBJQ0NfUFJPRklMRQAB
AQAAAZBBREJFAhAAAG1udHJHUkFZWFlaIAfRAAEAHQAWABIAIGFjc3BNU0ZUAAAAAG5vbmUAAAAA
AAAAAAAAAAAAAAAAAAD21gABAAAAANMtQURCRQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAABWNwcnQAAADAAAAAJGRlc2MAAADkAAAAcXd0cHQAAAFYAAAAFGJr
cHQAAAFsAAAAFGtUUkMAAAGAAAAADnRleHQAAAAAKGMpIDIwMDEgQWRvYmUgU3lzdGVtcyBJbmMu
AGRlc2MAAAAAAAAAFkdyYXlzY2FsZSAtIEdhbW1hIDIuMgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAWFlaIAAAAAAAAPNRAAEAAAABFsxYWVogAAAAAAAAAAAAAAAAAAAAAGN1cnYAAAAAAAAAAQIz
AAD/7gAOQWRvYmUAZIAAAAAA/9sAQwAMCAgICQgMCQkMEQsKCxEVDwwMDxUYExMVExMYEQwMDAwM
DBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AACwgBnwN+AQERAP/dAAQAcP/EAKIAAAEF
AQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMi
cYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj
80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3/9oACAEBAAA/AO9+tH1o
6f8AVfp9efn13W1W3ChraA1ztzm2WgkW2Ut2baXfnLl//Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cX
P/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3q
S/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A
3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/
96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr
/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp
/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev
6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7b
p/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8A
Hr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/
APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv
/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBx
c/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDe
pL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9
xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8A
epL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+q
v/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtu
n/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+
qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A
7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x
6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//
ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/
AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cX
P/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3q
S/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A
3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/
96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr
/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp
/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7bp/8AepL/AMev
6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8AHr+qv/cXP/7b
p/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/APtun/3qS/8A
Hr+qv/cXP/7bp/8AepL/AMev6q/9xc//ALbp/wDepL/x6/qr/wBxc/8A7bp/96kv/Hr+qv8A3Fz/
APtun/3qS/8AHr+qv/cXP/7bp/8AepdL/wA7+jf81/8AnTus/Z3p742H1N2/7P6Hp/R9X7T+r/T9
Df8A4b0P0q//0NX/AB1/+JXF/wDD9f8A55yl6Akkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkksev6wZF5tOL0jNyaqrraPWY7Ea1
zqLH4txY2/Opu2etS/8AnKmKX7Z6j/5RZ/8An4P/AMkkv2z1H/yiz/8APwf/AJJJftnqP/lFn/5+
D/8AJJL9s9R/8os//Pwf/kkl+2eo/wDlFn/5+D/8kkv2z1H/AMos/wDz8H/5JJftnqP/AJRZ/wDn
4P8A8kkv2z1H/wAos/8Az8H/AOSSX7Z6j/5RZ/8An4P/AMkkv2z1H/yiz/8APwf/AJJJftnqP/lF
n/5+D/8AJJL9s9R/8os//Pwf/kkl+2eo/wDlFn/5+D/8kkv2z1H/AMos/wDz8H/5JJftnqP/AJRZ
/wDn4P8A8kkv2z1H/wAos/8Az8H/AOSSX7Z6j/5RZ/8An4P/AMkkv2z1H/yiz/8APwf/AJJJftnq
P/lFn/5+D/8AJJCy/rHlYWLdmZPRM+vHxq3W3P3YR2sYDZY7azqLnu2sb+ai/Wz/AMSvWf8Awhlf
+ebFwH/5if8AX/ywX//R1f8AHX/4lcX/AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSyfq1/wAnXf8Ah/qP/t9m
LWSSSSSSSSSSSSSSSSSSWT9bP/Er1n/whlf+ebEvrZ/4les/+EMr/wA82LgP/wAxP+v/AJYL/9LV
/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ
JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJLJ+rX/ACdd/wCH+o/+32YtZVMbq3Ssu842LmY9+QK2
3Gmq1j3+m4MfXd6bHOf6T2W1OZZ9D9LWhWfWHoFbDZZ1PEYxvp7nOvrAHrNN+NLi/wD7UUtddR/p
av0latV5eLb6XpXV2faKzdRtcD6lY2TdVtP6Sr9NT+kZ7P0tf76jX1Hp9tXrVZNL6t1bPUbY0t3X
Ct2OzeHbd+Q3Ix/Q/wBL69Pp/wA6s+3rXUKbBfbgtr6acluILXWubk7n3jp1V32F2P6P2ezKeyyu
z7f78H9a/nP1ZaV2R6VlFfp2WfaLDXuY2W1wyy/1L3f4Or9D6O//AE9tNf56nddVRU+657aqqml9
ljyGta1o3Pe97va1jWqli9aws7Kqq6ffj5mPZXc5+RRfW/a+k4zfR9Ktzn2bmZe+yxv9H/Rer/Sq
UXG6t0rLvONi5mPfkCttxpqtY9/puDH13emxzn+k9ltTmWfQ/S1qHR+pO6ng/a30OxXetfS6h7mu
c00XW4h3uq3Vb3ehu/RvsZ/wtv8AOIWT1/p+F1C/Fz7qcOqmnHtbkX2tra52Q7MYKB6uxu9jenus
+n7/APrSWT1/p+F1C/Fz7qcOqmnHtbkX2tra52Q7MYKB6uxu9jenus+n7/8ArSWT1/p+F1C/Fz7q
cOqmnHtbkX2tra52Q7MYKB6uxu9jenus+n7/APrS01UwerdK6lv/AGdmY+Z6Uep9ntZbt3Ts3+k5
+zfsftUMbrnRcuq+7F6hjZFWK3fkWVXVvbW2HO33vY9zamba3/zn7ijX9YegW+l6XU8Sz7RYaaNt
9Z9SwbJpq2v/AElv6an9Gz3/AKWv99aCyfrZ/wCJXrP/AIQyv/PNiX1s/wDEr1n/AMIZX/nmxcB/
+Yn/AF/8sF//09X/AB1/+JXF/wDD9f8A55yl6Akkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkksn6tf8AJ13/AIf6j/7fZi1lx/1W
x8y/pH1ZrbgfZMfp9deW/Ia6s02izEyKP0La3DK+13W57cjJ9fEpq9T7V+s3/obMmx0zped0fC6D
bXgOtdg9OfiZWJjGlr233/Yr7bv092NivZ62FkfaLGZHqPuuZZ+l/S2Vyr6L1K3Gx6A37Fa+zqGU
/MDpspGVe/Jp6a/7NdS932hmU37a6jIfVW/p/wCqX15n7O6nigxcZ13UW9LqrpxqrXYXUuo4dT2v
fhW4tePs6fuob6FLLX4nSPsTHV/rOLR1qyp9f6or9VvUrerm7O6VkvbTc6rCe1+Kceqsk0/b4dmN
yrMjIpO+yz7L62LjWfYsaj+mXZ+xd9q9Sj0PT9L1D9q3zu9PZZt9Db7fV+0/Z/5z2eh63+E2Kv1n
GdldOsrZW66xrq7a2se2t4fVYzIrsofc19H2il9XrY9WT+q33V105X6vZasXpHT+tH6yV9SzKbvs
zMK7H9fM+yDL3utxbmU2fsn9XfhbK7H4n+Grv+3+t7LcZV/qtj5l/SPqzW3A+yY/T668t+Q11Zpt
FmJkUfoW1uGV9rutz25GT6+JTV6n2r9Zv/Q2ZO106nP6f0jLjH9bLbkZ+RRjb2t9T1cnKysRnre6
ur7RXbV7n/zW/wDSKvk1Z2J9ZL+q1dMdnVWYWPjMtpfSL2ubbmXXVsbl2Yzfs7m2Y7r/ANYZ+k+z
enTkfpX4tLpnTOp9Eysa13Tv2h6HSMHpxvxn0iwWUHJdkspGa/E/VH7qH2v9ap+/7L+r3fpvsi6Z
0zqfRMrGtd079oeh0jB6cb8Z9IsFlByXZLKRmvxP1R+6h9r/AFqn7/sv6vd+m+yW29J6kfqrZ9W3
Mra9vSK8OvL3zW+91NuJczZs9ZlVHp0W+t6f6VmR/N/olLPqzuudPz8U9MdgW3YWRjU5GY+kuDsh
oY2uv7BZnu+zucz1Mve+r+axvTpyf+09XrGJ1XrVWZYzp92I5vSs/CqqyH0brbcsYxoFX2XJyqms
Z9jd6rsiyj+dp/nP0vpWOt9Lz8r9v+hVv+39IrxMX3NG+5v7T3Ve5zdn9Lx/fZ+j/Sf110CyfrZ/
4les/wDhDK/882JfWz/xK9Z/8IZX/nmxcB/+Yn/X/wAsF//U1f8AHX/4lcX/AMP1/wDnnKXoCSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSyf8AnT0J
/wDRcr7fH0/sFdmbs/d9f9m15Xob/wDBet6fq/pPT/m7Ev2r1bI0wek2AH3NuzrWY1bmfmljKP2h
n12v9rvQy+n43s9T1/Ru/QJf9lV//cDp23/js7fP/uE+z+n/AOhPq7/8D6X6VfYPrBd7cnqtdLBq
HYOK2qyf3Xv6hd1en0v5LcZlu/0/0/067V+xuo/+Xuf/AJmD/wDI1L9jdR/8vc//ADMH/wCRqX2b
61f+WOB/7A3f/JVL1/rUz2fYsC7bp6v2u6rfH+E+z/s/K9Df9L0ftWT6X0PXu/nEv2/6X9O6bn4c
/wA3+g+1bo+l/wAjP6n6Oz2/0n0PU/wPqfpfTsYXW+kZ9pow8ym7JY3dZjB4F7ACGv8AtGK6MjHf
W93p213VVvqs/R2e9Xkkkkklk/Vr/k67/wAP9R/9vsxayqY3VulZd5xsXMx78gVtuNNVrHv9NwY+
u702Oc/0nstqcyz6H6WtCs+sPQK2GyzqeIxjfT3OdfWAPWab8aXF/wD2opa66j/S1fpK1ary8W30
vSurs+0Vm6ja4H1Kxsm6raf0lX6an9Iz2fpa/wB9Rr6j0+2r1qsml9W6tnqNsaW7rhW7HZvDtu/I
bkY/of6X16fT/nVn29a6hTYL7cFtfTTktxBa61zcnc+8dOqu+wux/R+z2ZT2WV2fb/fg/rX85+rL
SuyPSsor9Oyz7RYa9zGy2uGWX+pe7/B1fofR3/6e2mv89Tuuqoqfdc9tVVTS+yx5DWta0bnve93t
axrVSxetYWdlVVdPvx8zHsruc/IovrftfScZvo+lW5z7NzMvfZY3+j/ovV/pVKTuvdKLL/suRXnZ
GPjnKOHiPZbe+va26t1OOx+9/rssq9D8y31qv9IoYnUuoftBmB1LFpx7b6bL6HY97r2ltLqarxab
sbBdU/dmUelsbd6n6b+a2fpVk9f6fhdQvxc+6nDqppx7W5F9ra2udkOzGCgersbvY3p7rPp+/wD6
0lk9f6fhdQvxc+6nDqppx7W5F9ra2udkOzGCgersbvY3p7rPp+//AK0lk9f6fhdQvxc+6nDqppx7
W5F9ra2udkOzGCgersbvY3p7rPp+/wD60tNVMHq3Supb/wBnZmPmelHqfZ7WW7d07N/pOfs37H7V
DG650XLqvuxeoY2RVit35FlV1b21thzt972Pc2pm2t/85+4o1/WHoFvpel1PEs+0WGmjbfWfUsGy
aatr/wBJb+mp/Rs9/wClr/fWgsn62f8AiV6z/wCEMr/zzYl9bP8AxK9Z/wDCGV/55sXAf/mJ/wBf
/LBf/9XV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ
JJJJJJJJJJJJJJJJJJJJJJJKjm9YwsO0YxLr817d9eFQPUvc0ksZYa2/zGO61vpfbMp1GFVZ/P5N
Sr+n9YM73Pur6Tju4qqa2/LA+mx5ybt2Bj2/4O/G+xdSq/nPQzrPVrtpX/Njo1vuz6P2padTZnk5
MOP84+inI342F6zv52vBoxaP5v8ARenVVs1kkkkkkkklXzendP6hUKc/Gpy6mu3trvrbY0OALQ8M
ta5u/a5yo/sH7Nr0rMyMCNRRu9fGO3+Zq+yZnrfZcSv6H2fpdvTf0P6P1P0eP6K/aHVcDTqmN9qp
H/a3AY98f8f0ucjNq9zmVVfY7Oqb/wBJkZH2KpaGLl4ubQ3Jw7q8nHsnZdU4PY6CWO22VlzHbXt2
oySSyfq1/wAnXf8Ah/qP/t9mLWXH/VbHzL+kfVmtuB9kx+n115b8hrqzTaLMTIo/QtrcMr7Xdbnt
yMn18Smr1PtX6zf+hsybHTOl53R8LoNteA612D05+JlYmMaWvbff9ivtu/T3Y2K9nrYWR9osZkeo
+65ln6X9LZXKvovUrcbHoDfsVr7OoZT8wOmykZV78mnpr/s11L3faGZTftrqMh9Vb+n/AKpfXmfs
7qeKDFxnXdRb0uqunGqtdhdS6jh1Pa9+Fbi14+zp+6hvoUstfidI+xMdX+s4tHWrKn1/qitZuHnZ
mdUbOltZ1CjJrNXWmeiGNxK8j7T9nbab3dUa+/p3qYeRV9l9C3Kvv/7RW+st277V6lHoen6XqH7V
vnd6eyzb6G32+r9p+z/zns9D1v8ACbFX6zjOyunWVsrddY11dtbWPbW8PqsZkV2UPua+j7RS+r1s
erJ/Vb7q66cr9XstWL0jp/Wj9ZK+pZlN32ZmFdj+vmfZBl73W4tzKbP2T+rvwtldj8T/AA1d/wBv
9b2W4ypdBr6m76vfV/7J0rb+zMcZrC22llOS5+Fk0100vDvtFWXlZGdXbkvycOqiqz7V+s5H6KzJ
1+nW9Sqqy739KyX9SfS6112Q/FrbfZWD9nwKPs2ZnOw8fc97cat/6Gn9NfkX3Zd19+SsmrOxPrJf
1Wrpjs6qzCx8ZltL6Re1zbcy66tjcuzGb9nc2zHdf+sM/SfZvTpyP0r8Wl0zpnU+iZWNa7p37Q9D
pGD0434z6RYLKDkuyWUjNfifqj91D7X+tU/f9l/V7v032RdM6Z1PomVjWu6d+0PQ6Rg9ON+M+kWC
yg5LsllIzX4n6o/dQ+1/rVP3/Zf1e79N9ktt6T1I/VWz6tuZW17ekV4deXvmt97qbcS5mzZ6zKqP
Tot9b0/0rMj+b/RKWfVndc6fn4p6Y7AtuwsjGpyMx9JcHZDQxtdf2CzPd9nc5nqZe99X81jenTk/
9p6vWMTqvWqsyxnT7sRzelZ+FVVkPo3W25YxjQKvsuTlVNYz7G71XZFlH87T/OfpfSsdb6Xn5X7f
9Crf9v6RXiYvuaN9zf2nuq9zm7P6Xj++z9H+k/rroFk/Wz/xK9Z/8IZX/nmxL62f+JXrP/hDK/8A
PNi4D/8AMT/r/wCWC//W1f8AHX/4lcX/AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSo5vVasW0Y1dN2ZmObvbi47Q520kgPtttdTiYrH7Lf
S+2ZOP8AaPRuqxvWuZ6ar/Y+uZumdlV4WO76WNghxsj6Lqn9Uv2PdVazc79U6f0/Mpf6foZn6H1b
72F0/CwKjVh0tpa92+wjVz3kBr78i1025GRZt/S5Fz7Lrf8ACWKwkkkkkkkkkkkkks/K6Ji3XuzM
d9mBnPjfl4pDHvgCtv2muxtuLm7Kv0VP27Hyfs3/AGm9Gz3oP7Q6rgadUxvtVI/7W4DHvj/j+lzk
ZtXucyqr7HZ1Tf8ApMjI+xVLTpuqvqZdS9ttVrQ+uxhDmua4bmPY9vtcxzVNZP1a/wCTrv8Aw/1H
/wBvsxayzOn/AFj6P1J1Iw7nWNyG7se01Wsqs9vqOqoyra2Y92RWxtnq41dv2in0cj1av1a/0xU/
W3oV9TLsa27JrtaH1GjGyLd7SPc+ltNFjrWUOLasz0/6FkPrxcv0MixlSu4/VMDJfRXTbufk12W1
N2uB20OroyRY17W+jbj3X103UXenfXb+j9P9FahY/X+k5OL9sov34/qUVb9jx78sY9mG3a5gf+mZ
n4n/ABfq/pdnp2qpm9byq/rFgdNxWVuxH2Opz7XAlzbH4+TnYtOO9jvTbbXXhermV3M3+hl4Hp/0
hat1l7LKG1U+qyywtvfuDfSZsssF21387uuZTj+mz/T+r/gksrKow6HZGQ7ZUyJMFxJcQyuuutgd
ZbbbY5tdNNbfVut/RVfpFn4vXsbN6rVhY79s4911uPkU30ZPsfjV03Mqyqqf1T9Nex1j/wCeu/o3
9Hy/TjV9aOnZuObOlF2bbbS6zCaWWU1ZDww3NxaM/IqbifaPa71afU9bG9LI9er9VyPTh0vquVb1
Wzp1uXidS9Oux19mEw1/ZrKn1VDFzGOyuofpcr1bvR3vxn/qOR7Lv8BPJ+sNOH1q/p+TuLWY2PkU
soptvvcbbMyrIeacRl9v2er7NjfpfR2VWX/pbf09Kg/6zYdXVbMV7/Wx3YmNl4pxa7MmywXPy2W3
Nrwm5D34jGY+L+nbV6TH3++39PQk/wCs2HV1WzFe/wBbHdiY2XinFrsybLBc/LZbc2vCbkPfiMZj
4v6dtXpMff77f09C1fteL9l+2+tX9k9P1vtG4en6cep63qz6fpen7/U+hsVXH690y/1JfZjejW65
/wBrpuxP0bP565v2+rG9Sqjcz17K/ZR6lXrfztag36xdKNWRa991DcWl+RaMjHvod6VY3X3VVZVN
NuQyn2+r9nZb6fqU/wCmqUP+c/SB9N2RVGtnq4uTX6bP+5GV6uOz7JifT/XMr0cX9Dk/pv1XI9LW
WT9bP/Er1n/whlf+ebEvrZ/4les/+EMr/wA82LgP/wAxP+v/AJYL/9fV/wAdf/iVxf8Aw/X/AOec
pegJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJLJ+339W9
vRcituGNLephoua4nR1PTfd6NttX+EzbPtGHj3/q32bOt+2VYV7C6fhYFRqw6W0te7fYRq57yA19
+Ra6bcjIs2/pci59l1v+EsVhJJJJJJJJJJJJJJJJJZl3RW1Wvy+kvb0/LscX2+1z8e1zzN1mVgV2
49VuRZ9L7ZW+nN/R078mzG9TGtLhdUqyLTh37cbqVbd12GXAu2ghv2nH+g7Jwnud+iym1/8AA3sx
8uu/Fpr/AFa/5Ou/8P8AUf8A2+zFrLl/q703rT+nfV9mfXTRV0umq5rgbBe5xxLMIYmRhW17cZ9D
cx3q3fbLvUsxv6LR9o9PFsYvR+q9PxejPxm4+Tl9MwDgXVWWvqrdvGH6l9eQzHybP0dnT9rKnYv6
Rl2/1KvS9O1f83L8jDpwcx9Yx3WZmXk+mA57b8qyy6qmh+RU+u3EprzsyrI9Smr7dspqyMf7DlZ2
DaGnAzcnqzacjSo/Zs3rDa6rG0OzsdlYp+x5ORssvqvsZhX/AKtY9mJ+xPs+Wz1Op3I1v1YyW9Tx
c3H6jkelXnvzsimwUEe+nIo2V2fZPtNntuqw2faMn9D079FRYyyjF9PaurvfZQ6q70mV2F17Nod6
rNllYp3O/mttz6cj1Gf6D0v8KhdUxX5eBbRW2t73bXNbaXNaSxzbGxdQRdjW+z9BmU/pcK/08quq
30fSWP0jofVsfrVfUMp7a8WvGuobiHKvznNstsxbftDc3Prqv2XMxfSfi/zOP6FdtO/7XkenV6R0
n6w5HQ+i49zqcB3TsZllGSA917bXYd2BVVkdNyK21VPxPtu+1/2y317MT+jY/wBp/VdI4vX78o9R
sqxMbLxsTIx8Ktt1mRW+zIOPax+U842DZTVTZg1+2plz7WXP/mvS/SzycTrVPWr+pYDMa+q/Gx8d
1F9llLt1NmZcbRfVTltaxrctrPS9D9N/psf7P+tVMLovWuj21HA+zZlVXTsPp7mXvsx3OdiHKnJF
lVWa2tm3Ib+r+lb6m/8ApFP2f9bWF0XrXR7ajgfZsyqrp2H09zL32Y7nOxDlTkiyqrNbWzbkN/V/
St9Tf/SKfs/63Yb0LK/YFn1dffX9k/ZleBVkhh9T1PTtxci+ynf6fpen9lspqbbv3+vvs/m1PJxO
tdW6fnYGezGwasvGtx2uossynbrm+kLSbaenNrZQ3d+i22/aN/8APY3o/p6nUukda6xVlnKrxsS1
3TszAx2VXWXtc7MFP6W+x+LiOoZQ7EZ/N1ZHq+t/g/R/TWOrdEys39tek+tv7T6YzBo3EiLG/tCX
27Wu21fr9P0N7/5z9GttZP1s/wDEr1n/AMIZX/nmxL62f+JXrP8A4Qyv/PNi4D/8xP8Ar/5YL//Q
1f8AHX/4lcX/AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSShddVRU+657aqqml9ljyGta1o3Pe97va1jWrM239a9uRRZi9L/OouAbZlA6t9aoOc
/H6fs/nMXI9LMy3/AKtm4+Ni1X4/UNZJZ+V9YegYV7sbM6niY2RXG+m2+tj2yA9u6ux7Xt3MduQf
+dn1V/8ALnA/9iqf/Sit4PVuldS3/s7Mx8z0o9T7Pay3bunZv9Jz9m/Y/araSSSSSSSSSSSqZ3Vu
ldN2ftHMx8P1Z9P7Rayrdtjfs9VzN+zezcqn/Oz6q/8Alzgf+xVP/pRWMLrnReoWmnA6hjZdrW73
V0XV2ODQQ0vLKnuds3Oaryr5uFVm1Bjy6uyt3qUX1wLKrAC1t1LnBzd+1z2Oa9j6bqX2Y+RXdj3W
1Pz/AKqC0dJeLnNfaM3qAsexpY0u+25e9zK3PtdWxzvzPVs/4xbCSSSSSSSSSSSSSSSSSSyfrZ/4
les/+EMr/wA82JfWz/xK9Z/8IZX/AJ5sXAf/AJif9f8AywX/0dX/AB1/+JXF/wDD9f8A55yl6Akk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkg5WVRh0OyMh2ypkS
YLiS4hldddbA6y222xza6aa2+rdb+iq/SKlTiZudazJ6ntroY4W43TmidjwZqsz7m2WVZeRTtbbT
VS1mLiZH/c+7Gw8+uxndUwOn7BlW7bbp9GhjXW3WbY9T7PiUNtycj0mu32+jU/0q/wBJZ+jVT1vr
Jl60UY/S6jq1+WTk3ae0124WFZRjVbne9l1fVsr9H/gPUt/V1/zdxb/+VL8jq3bZlvHolv5rLen4
jMXpt+x/6VlmRh23+p/hf0NHpaGLiYuFQ3Gw6a8bHrnZTU0MY2SXu211hrG7nu3IyqZ3SeldS2ft
HDx8z0p9P7RUy3bujfs9Vr9m/Yzcqn7Fysb3dL6jkUxr6GWTm0ucfa59py3/ALS+h9CvH6njUMs/
Sel/P+uv2l1XC/5UwvUpGn2vA338e31L+n+n9tp9Z2z0qcP9rej+k+0X+lT9os0MXLxc2huTh3V5
OPZOy6pwex0EsdtsrLmO2vbtRkkkkklC66qip91z21VVNL7LHkNa1rRue973e1rGtWZ+2MrM/wCR
cP7XUNfteQ842M4f91rfRycnK3tdXbTkUYf7Ovp/ms/1P0SX7J6llf8AKfU7HM4dj4LfsdbgPc1z
7RZk9TZbv/Oxup49T2enV6H8/wCvbwek9K6bv/Z2Hj4fqx6n2eplW7bOzf6TWb9m9+1W1XzendP6
hUKc/Gpy6mu3trvrbY0OALQ8Mta5u/a5yo/sH7Nr0rMyMCNRRu9fGO3+Zq+yZnrfZcSv6H2fpdvT
f0P6P1P0eP6K/aXVcL/lTC9Skafa8Dffx7fUv6f6f22n1nbPSpw/2t6P6T7Rf6VP2izN+r31i6bX
gWhoyb2uzc97LcfEysipzX5mVZW+nKxMe7HuY5j/APBWrQt+tfSaWh9rM2tpc1gc7p+a0bnuFVTJ
difTsteyuv8Afepf85enf6HP/wDcdnf+8aX/ADl6d/oc/wD9x2d/7xpf85enf6HP/wDcdnf+8aX/
ADl6d/oc/wD9x2d/7xpf85enf6HP/wDcdnf+8aX/ADl6d/oc/wD9x2d/7xpf85enf6HP/wDcdnf+
8aX/ADl6d/oc/wD9x2d/7xpf85enf6HP/wDcdnf+8aX/ADl6d/oc/wD9x2d/7xpf85enf6HP/wDc
dnf+8aX/ADl6d/oc/wD9x2d/7xpf85enf6HP/wDcdnf+8aX/ADl6d/oc/wD9x2d/7xpf85enf6HP
/wDcdnf+8aX/ADl6d/oc/wD9x2d/7xpf85enf6HP/wDcdnf+8aX/ADl6d/oc/wD9x2d/7xrP+sPW
8XN6B1PDxsfPsyMnEvqpZ+z80bnvrfXW3c/Eaxu57vzlofWz/wASvWf/AAhlf+ebFwH/AOYn/X/y
wX//0tX/AB1/+JXF/wDD9f8A55yl6Akkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkksnA/ytfj9adphtrcemVHUubcG/5Suaf5q22n9HhV/wA/j4eRk/af0udbh4Rs
rMyrr3YPSzX9oqg5OTa02U0SBYyp1VdlD8jLuY5rvs7L6vQx3/a8iz34dGcXB6Zi4O99Td+TfBys
t4Buuc2dr8i1rWb9m93pV/zGNX+gxaqcfZUraSSSSSSz8rpU3uzumurwuo2QLbzXvZc0AMazOpY/
Hfk+kwfq1nr1343+Dt+zW5WNklwc77TvpuZ9nzceBkY5O7bun07arIZ6+Jfsf9nyNnv/AElVtdGX
Rk41FtJJJBysqjDodkZDtlTIkwXElxDK6662B1ltttjm1001t9W639FV+kVKnEzc61mT1PbXQxwt
xunNE7HgzVZn3Nssqy8ina22mqlrMXEyP+592Nh59emkkkkkks/K6Ztvd1Hpra6Oouj1SRtZktaA
xtGc5jXPdtY39Wy9ll+D/g/VxvtWFllx8jF6ni2MfXLTuoy8S9oLmOI/S42TV76/5t//AAlGRRZX
fRZdjXVW2V+m3W4dtfRct7rra6S/EynEudfRUa6bH5Lj7m5tDr6G5X+DyvWZlY/85kYmDppJJJJJ
JJJJJJJJJJJLJ+tn/iV6z/4Qyv8AzzYuA/8AzE/6/wDlgv/T1f8AHX/4lcX/AMP1/wDnnKXoCSSS
waqupdQ6l1UDquTiVYmSyimmhmKWhpxcPKcS7Kw8m5z3XZNv+FVj9jdR/wDL3P8A8zB/+RqX7G6j
/wCXuf8A5mD/API1L9jdR/8AL3P/AMzB/wDkal+xuo/+Xuf/AJmD/wDI1L9jdR/8vc//ADMH/wCR
qX7G6j/5e5/+Zg//ACNS/Y3Uf/L3P/zMH/5GpfsbqP8A5e5/+Zg//I1L9jdR/wDL3P8A8zB/+RqX
7G6j/wCXuf8A5mD/API1L9jdR/8AL3P/AMzB/wDkal+xuo/+Xuf/AJmD/wDI1L9jdR/8vc//ADMH
/wCRqX7G6j/5e5/+Zg//ACNS/Y3Uf/L3P/zMH/5GpfsbqP8A5e5/+Zg//I1L9jdR/wDL3P8A8zB/
+Rqr21dS6f1LpQPVcnLqy8l9F1N7MUNLRi5mU0h2Lh41zXtuxqv8Kt5JJJBysvFwqHZOZdXjY9cb
7rXBjGyQxu6ywtY3c921Z/8Aziou06diZfUTyDTSa63M/wBPTm9QODgZNTvb6f2bKu9Zj/Wp9Snf
Yl6n1nyf5unE6aw+5r7nPy7I/NpuxKPsFNNuv6SynqeZVW9npV/aN/2hL9mdau92T1myl40DcGii
quP3ns6gzq93q/ym5LKtnp/oPp2Wr9jdR/8AL3P/AMzB/wDkal+xuo/+Xuf/AJmD/wDI1L9jdR/8
vc//ADMH/wCRqX7O67R/Rer+tu+n9vxq7Yj6Pofs13Rtn/C+t9p/wfp+j+k9VfbfrBjf0np1eYwe
0Pwb2+o4/wCmfidQGFTjVPj+bb1PMtpf6dX6x78hL/nN0mvTOfZ0wjRxzq349Yf+dQzNva3AyLfp
f0TKyPVYyy6j1af0i1kkkkkkkkkkkkkkkkkkkkkkkklk5n+VM89LGuFi7bOpTqy31G2ej0w7f+tZ
mdW9/wDRfsmPZRk4nU7vSNlZV+Re7p/T3bLWR9ry4DhjhwD211teHV29Qtrdvppf+ixqv1zM/R/Z
MTqFrFxaMOhuPjt2VMmBJcSXEvsssseXWW222OdZddY71brf0tv6RGSSSSSSSSVTOwftOy6l/wBn
zceTj5AG7buj1Kra5Z6+JfsZ9ox9/v8A0dtVlGXRjZNCwc77TvpuZ9nzceBkY5O7bun07arIZ6+J
fsf9nyNnv/SVW10ZdGTjUW0kHLyqMLFuzMl3p4+NW6258E7WMBssdtYHPdtY381VcXFvyL29Q6g3
ZayfsmJIcMcOBY6yxzC6u3qFtbtl1zP0WNV+p4f6P7Xl9Q0EkkkkkkklRzcK11ozsEtrzq27PfIr
urBLvsuVtDnbNznuxslrH3YVz/Ur9ai7Mw8sVgq670v1MdzsXIa6wY9zmg2Y2VSbMV7trH7LH417
bqL2Mufi5lPrUepfh5H6Sx03O+20Oc9no5FNj6MmidxZZWdrtYY91VrNmTi2WVUvvw78fI9Kv1lb
SSSSSSSSSSSSSSSSWT9bP/Er1n/whlf+ebFwH/5if9f/ACwX/9TV/wAdf/iVxf8Aw/X/AOecpegJ
JJLJ6N/yj13/AMPs/wDbHpq1kkklC66qip91z21VVNL7LHkNa1rRue973e1rGtUMTKozcWnMxnep
j5NbbaXwRuY8Cyt214a9u5jvzlNl1VjrGVva91LtlrWkEtcWtt2WAfQf6Vldn9SxTQcbKoy6zbju
3sbZZUTBHvpe/Gvb7g36F1VjEZJJJJJJJZPWf+Uehf8Ah9//ALY9SWskq+b1DCwKhbmXNpa92ysH
Vz3kFzKMeps25GRZt/RY9LLLrf8AB1qj9o6z1HTEr/ZmI7/tTkNDsl7T+djYP83i763+pTf1B/r0
XM9HL6KjYvRMWm9uZkPsz85k7MvKIe9kg1u+zV1tqxcLfV+iu+w4+N9p/wC1PrWe9aCSSSSSSSSy
f+bmFRr0l9nRifpDBFbK3D87fhX1ZGB6rvZ+tfZftmyqun7R6P6NL9odVwNOqY32qkf9rcBj3x/x
/S5yM2r3OZVV9js6pv8A0mRkfYqloYuXi5tDcnDuryceydl1Tg9joJY7bZWXMdte3ajJJJJJJJJJ
JJJJJJJJJJJKp1LO+xUNcxnrZF1jKMaidpfZYdrdYe9tVTN+TlWV1XPow6MjI9Kz0VSeLeh9Erxs
dzcnqVzvTpc9pDbs3Ic627JsoY/ezH+0WX9QzKsf+i4VeT6P6OhaGFhVYVRYwusssd6l99kGy2wg
Nddc5oa3ftaxjWsYymmllePj1049NVTLCSSSSSSSSSSzOsU247T1bCY52XjNHrVVgudkY7Hepfi+
i3+fyG1Ovs6Z9D0832eszGys2u/QpuqvqZdS9ttVrQ+uxhDmua4bmPY9vtcxzVNZOT/lPqowOcLA
9PIyyPzskPZkdPxvUbu/o3o/bsun9Dd+k6V/OYmTkVWaySSSSSSSSSSybv8AJnVmXt0w+q2bMonU
My9ldOFfvdHpVZNOP9gs9/vzP2ZXjU+rkZVlqzv8m9So6gz24uZY3Fz2jg2W7KOnZrm+7da25tXT
XekzfbVmUWZNv2fplWzWSSSSSSSSSSSSSSSSWT9bP/Er1n/whlf+ebFwH/5if9f/ACwX/9XV/wAd
f/iVxf8Aw/X/AOecpegJJJLJ6N/yj13/AMPs/wDbHpqpfWLJxa+tdOpz867B6fZjZjrzXa/Hrc5l
nTxR9pyqdjsVjXWO9K/18b9N+qet+t/ZsmrhDI6jldNxrsvJGG+nqj2+lc+s30U5mJT0qx+VW5uT
az7FZTdTmV3/AGjKZ/OZN1OVk/aIfba/tG77dZ/zh/afpfYPtL932T7b6E/sb1fs/pfsL9Y9f7F/
Mf5S9T1f1pTy3dQzBdg4mbdVVfd1CnpmWXOa5+aa8prsTIsre+5mF0+77e7Df9m/7z6P5n7Dh39c
1ei5tvU83K6iwXVYTqceiui+WubfX62Rmn0pfU19f2yjAyff6n23AysW3+iqX1T/APEr0b/whi/+
ea1exnVOuyxXjupc24C2xzA0XO9Kh32it4/n2NqdXi+r+/jeh/gVy/X80Y3Vrzbl7rW7HY2OzOuw
8poDGbaendH9J+D162y/1LMezI31ZeXb+yr/ANHiITs6s5eGzqvUcjFwX2daFzxc+lh9HqFVOGzJ
y6y1+LVQw+lj2evjf4LB9X08n7Lkbv1f6g1+JRjXXOstudmPw3O3PNmJj5Joxb/tDt3rs+yX4Hp5
Flnq5jLftPqX/pLVz+d1ayrrLTj2uGT+0aaLK7M683sqflV4djrfq9TQem0YVuPZ6eFl3vr9THvw
s31v2nkVepXq63dXm4zsWzIe+/7QMtlWZbm5rduLl5bcfJ6Pfj/sjpPVXZGPW9mHV/2pouwsam3C
+1q30TrdNHW66ftFbsG/HfvfRn5PVa3XnIwcPEr+05lLWY9rH5+2ynGt+hk1XZ3p1/ZLFpdXyOnN
61ZV1vPdgYTcal2ETl2YLX2usym5223HuxPtT66q8DfW99v2b1K/5r7T+lzeo51baupvu6jkM6vT
W09Botufi3X/AKpj3Yr/ANj1nDpzrb+qvya3129Ps9XI9TA9LZR9lrsZ7LHZXVcr7Rktsr6rg4Vb
WZN7K20ZLOk05NbMau1uOx72Z2V+n9L7RTdZ9optrvrqsWv0Ivru6phepZZThZbasf1Xute1jsbD
y3NdkXusyLv1jKvf+mts/wBF/NV1sS6z/wAo9C/8Pv8A/bHqS1lk/tPK6l/yC7HsxuHdTtJtp3c7
MOih1f7Q2x6WRZ9sxaMex/stysijLxKbGF0nHxbTlPc7Lz3t2Pz7ww3lkhwoDqa6aqcduxv6vj1U
0+p+sen9ptuusvJJJJJJJJJJJJLPyukMfe7NwLPsGe+PVyK2NcLg0BtdWfU4frVTNjPz6cymr1Ks
TMxfXu3rF6rN7cHqTa8LqNkmqgWb2XNAL3Pwbnsx35PpMH6zX6Fd+N/hKvs1uLk5Ogkkkkkkkkkk
kkkkkkkkksnpv+Uc13Wj/RxW/F6c3ua/UnKzdzfY+rqT8fFfi/zzPseNj5VNv69fRWq/176wXPd7
sfpNbaqh2GXe31skvY//AAuPgOwvs19f+C6lnUepb6ltdOskkkkkkkkkkkksnp/6h1XJ6WdKcrfn
4XlveP2pR+c79Fm5FeZ6tr/f+1Ps+PX6WEtDLyqMLFuzMl3p4+NW6258E7WMBssdtYHPdtY381Ve
hYt+P02t+Y3Zn5X6zniQ4i+333Veo0v31Yv9Dxf0lvp4ePj0+rZ6S0EkkkkkkkkkkHLxaM3Fuw8l
vqY+TW6q5kkbmPBrsbuYWvbuY781Z/TP8rdCfi9S/WN32jAzH/Q9b0bLum5F+2nZ6H2v0X3elV/M
er6fqez1EbomVfdivx8x2/OwLDi5b4A3vYG2V5O2sekz7bi24+d6NX9G+0/Zv5yl60Ekkkkkkkkk
kkkkklk/Wz/xK9Z/8IZX/nmxcB/+Yn/X/wAsF//W1f8AHX/4lcX/AMP1/wDnnKXoCSSSyejf8o9d
/wDD7P8A2x6atB2LQ/KrzHNnIprsqrfJ0ZaarLm7Z2e9+NR/mIyShdU26p9Ty4NsaWuLHOY6HDad
ltRZbW//AISt+9ihi4tGHQ3Hx27KmTAkuJLiX2WWWPLrLbbbHOsuusd6t1v6W39IjJJILsWh+VXm
ObORTXZVW+Toy01WXN2zs978aj/MRkkkkkkklj9fuqozOi3XPbVVVm2vsseQ1rWtwOpOe973e1rG
tUvTyusaZVX2fpLtRQ8kXZLfzWZ1L2M+yYn+Efhb7b8ut9VOf9k/XenZGskkkkkkkkkkkkkkkg5W
LRmUOx8hu+p8SJLSC0h9dldjC2yq2qxrbKbq3erTb+lq/SKlTl5uDazG6ntsoe4VY3UWmN7yYqrz
6W111YmRdubVTbS5+Ll5H/cC7Jw8CzTSSSSSSSSSSSSSSSSSWZ1+60YTMPHe6vJ6lczErcwlr2tf
L826i3/BZGN06rMysex/+Gor/nn/AKGy7+q4OL/g8bExq/Kuuuusf2a6qqq2/wBRjFS+rtNrelsy
chjq8rPc7MyGWAixjsg+szFuL/e9+BQ6np7XP/wOJX+ip/ma9NJJJJJJJJJJJJZPWv0OZ0nO+gyn
L9HItHPp5NduJVS7b731X9Ts6Zur+h6rKMi3+j+rUvrF+moxOnDnqOXTSQfoOrrJ6hm03/vVZOBg
5WN6e17LvW9G79DZY9aySSSSSSSSSSSSycD9W671PFf/ANrfSz6nnTd+jr6bkUVt/wAL9l+w4t11
rfoftGit9bP0dl66h+odVxuqDSnK2YGb5b3n9l3/AJzv0WbkWYfpVM9/7U+0ZFnpYS1kkkkkkkkk
kkkkkklk/Wz/AMSvWf8Awhlf+ebFwH/5if8AX/ywX//X1f8AHX/4lcX/AMP1/wDnnKXoCSSS5/G6
lT03qnWGZVGX+ny2W0vqw8m9jmfZMGjc27Fx7qv52m2v6f5itf8AOXp3+hz/AP3HZ3/vGl/zl6d/
oc//ANx2d/7xpf8AOXp3+hz/AP3HZ3/vGl/zl6d/oc//ANx2d/7xpf8AOXp3+hz/AP3HZ3/vGl/z
l6d/oc//ANx2d/7xpf8AOXp3+hz/AP3HZ3/vGl/zl6d/oc//ANx2d/7xpf8AOXp3+hz/AP3HZ3/v
Gl/zl6d/oc//ANx2d/7xpf8AOXp3+hz/AP3HZ3/vGl/zl6d/oc//ANx2d/7xpf8AOXp3+hz/AP3H
Z3/vGl/zl6d/oc//ANx2d/7xpf8AOXp3+hz/AP3HZ3/vGl/zl6d/oc//ANx2d/7xpf8AOXp3+hz/
AP3HZ3/vGs/I6l0/r2b0M4lGRk49eX9r9W3DyGUhgxcz7PkjIyserH/pFuM6h/qfznp+kumSSSSS
SSSSSSSSSSSSULqar6n03MbbVa0ssreA5rmuG17Hsd7XMc1Z9F1vTsqnp+S912PkuLMDIeS6wOax
97sLKc6X2vZRTdbjZrv56mr0s39crryepaaSSSSSSSSSSSSSSSSyf6Z9ZPGnpWP/AFmHJyj/AJtO
Xg4WP/x32XrP+Bqs/WV9aPf0W7GP0M6yjBtPcV5l9PT8h9f/AArKcmx1O72er/g7PoLWSSSSSSSS
SSSSSWT9afZ0LKyufsHp5+z9/wCxWV9S9Dd+Z6/2X0fV/wAF6nqenZ/NpZ/6b6wdKxnaMprys5pH
PqVNp6exjv8AgvR6vkud+f6rKP0n84y3WSUBdUbXUh7TaxrXvrBG4NeXtre5n0mssdVbs/4uxK66
qip91z21VVNL7LHkNa1rRue973e1rGtQsLqPT+oVG7AyacuprtjrKLG2NDgA4sL6nObv2uaisuqs
dYyt7Xupdsta0glri1tuywD6D/Ssrs/qWJMuqsdYyt7Xupdsta0glri1tuywD6D/AErK7P6liTLq
rHWMre17qXbLWtIJa4tbbssA+g/0rK7P6limkkkksnqP6DrvSMr6XrfacDZxHq1t6l6+7+R+xvR9
L/uz6nqfofTt0MvFozcW7DyW+pj5NbqrmSRuY8Guxu5ha9u5jvzVV6DlX5XTGOyXepkUWXYt10Bv
qPxbrcGzJ9NgDKvtL8f7R6Lf5n1PSWgkkkkkkkkkkkkkksn62f8AiV6z/wCEMr/zzYuA/wDzE/6/
+WC//9DV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJJJJJJJJJJJLJzf8sWZPSGaYNf6HqdnDn+ox
lp6fR+c31ca+p+Xl/wCCou9HD/W7LMjpuskkkkkkkkkkkkkkkkkkkq/UMKrPwrsO0uY25sCxkB7H
D3VZFD3B3p5GPaGXY9v+CurrsQem5tt7r8TLDW5uG5rbtktZY17d9OZj1vLrW49/vr92/wBLKoy8
T18n7L9osvJJJJJJJJJJJJJJJLJ+rH6Xo1Ge7W3qk59hOrh9pP2imh9n0rvsWM+jBrt/0GLV+jqr
/RMX1l/5Op/8P9O/9vsNaySxMz60dPGFlW4t2y2vHutxr8mjIbi2Gut97XVZPotrzavTrdkfqFl9
t2JXbfj+pWrF/wBY+j4+Vdi2XO9XFcG5W2q17adzGXstzLqq304mO6m31PtOQ+rH9l/6X9WyPSnZ
nZTOv4/Ttlf2S/EvyPUkmz1KbMWrZshtbKvTy/pb7H2v/wBD6P6wuu9T/ZXTxml1bGNyMau19phj
a7sijFyLHO3M2enTdY/e72MVTP8ArNh1dPfmUP8AS9DIxK8huZXZjGunIyKcWzIfVmNxbWVek/I9
HJ/o/q0WfT9C5iWf9ZsOrp78yh/pehkYleQ3MrsxjXTkZFOLZkPqzG4trKvSfkejk/0f1aLPp+hc
xaGD1TDz94xzY19Ub6r6rKLAHT6dn2fLrou9KzZY2u70/SsfVb/orELK690zEvdRe+yao9exlN1l
NUgP/W8umqzFxNtTmX2fabqvSx3syLf0L/USyuvdMxL3UXvsmqPXsZTdZTVID/1vLpqsxcTbU5l9
n2m6r0sd7Mi39C/1FC/6xdKx8q7Fsfd6mO4Muc3HvfWHuYy6qj7TXS/HdkXMup9DHbb61111OPVX
69tdat4Wfi59RtxnOIY7ZYyxj6rGOADtl2PkNqvpfsey1vq1/wAzZXd/NWMVhZP1s/8AEr1n/wAI
ZX/nmxLJ/wDFV07/AMIZ3/n7pS1lj9eu6kLcanBfcA9tj7K8M4v2s7DU1j62dX/VHYVfqv8Ate39
Y9ezA9P9F66wruuZlVeZk15ddVtNfTKrMvJpraayepZ3Ts1uf6bm12/Z66rKcn0MmrD9X7TldO+y
V5C1TYyjJzen9XyrM3ExK8HOruua0Xes+/I9CljOnVYrbv1np2L9loZjvyL8i30P1j1aqFdw6nVZ
F/V+oFuLbmNox20Oc2K2Mfb9jptslzLM26/Os9T0X+jvspxMf7R6X2vLwsnIzMa/6152Jn+k/pdg
yxhMbW71C3Aw7Gfbjc2677Jf9m9Gv7L9it9mX+s2fo/sqycjMxr/AK152Jn+k/pdgyxhMbW71C3A
w7Gfbjc2677Jf9m9Gv7L9it9mX+s2fo/sqycjMxr/rXnYmf6T+l2DLGExtbvULcDDsZ9uNzbrvsl
/wBm9Gv7L9it9mX+s2fo/su71rqDqcF/2O5ov+04uHY5u1zqjk3Y2O92x29jcivHzPtFHrVvZ/Mv
sptpVTNtzum4ltLepuy77LsOoOtZT9opbl5LMB9/6vXRjuZsc9+F62F/SaLvW+10/q9NXPy+q4T8
rprOoXWOa7pbq82xlHrsGdmv6fk1tbXjV4extGP+h9TEe/1Lbf5z9F6SOX1XFtybHdQuyG9P6jid
PFVrKA25mUcA23ZPoY1Nv2ir9q2eh9lsxqf1bF9Wi79Z+09QsnrP/KPQv/D7/wD2x6ktZZOB+rdd
6niv/wC1vpZ9Tzpu/R19NyKK2/4X7L9hxbrrW/Q/aNFb62fo7L9ZJJJJJJJJJJJJJJZP1s/8SvWf
/CGV/wCebFwH/wCYn/X/AMsF/9HV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJJJJJJJJJJKj1jNt
w8InGDX5t7hRhVvktdfZ7azYxhba7Ho92Vmel+kqwqMm/wDwSN0/CqwMKnDqLntpbBsfBe9x91uR
e9ob6mRkWl92Rb/hbrLLFYSSSSSSSSSSSSSSSSSSSSWZ1ym1lVXU8VjrMrprjaK6wS+2gjbnYbWM
99z7qP0uLj72V2dSx+nvu/mVoU3VX1Mupe22q1ofXYwhzXNcNzHse32uY5qmkkkkkkkkkkkkksn6
0+/oWVi8fb/TwN/7n22yvpvr7fz/AEPtXrel/hfT9P1K/wCcWssn60ezot2SfoYNlGdaO5rw76eo
ZDK/+FfTjWNp3ez1f8JX9NayS5K/6sdZtxMvCpNOJXdjZGOCzLyraLBZTZj00s6Vksfi9Hx23WU5
P6lbkvxK8f7BT6tF1iLkdN61l2/WLBqrpbhdVu9E3XGyt9bbMHCxbcvHa2u6rqDPptbTvwv02LZX
9q/Tfqu1bhWv61i54LfSx8bJoe0zuLr7MK2stEbdm3Dt3+7/AEar9Xweq5+Hfj1Px6nty8W/Ce4P
cBXRZiZdn2qsFnqW+tRlbK6rKmWVfZ/0tX6SxUsvovWs/wC05Vn2bEzbndPbVW19mRU1uBlO6j61
jzVgW2Pt9eyv7Nsq/mf6X+n/AFdZfRetZ/2nKs+zYmbc7p7aq2vsyKmtwMp3UfWseasC2x9vr2V/
ZtlX8z/S/wBP+r28fE619ryOpWsxqMrIbiY/oNssurFFF112Rb65pw3/AGi2jOyGUVeh6dd1NPqX
P9X9EjidaxM7NfgMxrKuo3NvddfZY11LhTj4JAxKqbG5jGNxG5H9NwvV9T7P+h/pCr9R6P1W5vV8
PGbjuxOuT62RZa9llHqY9PTLPTxWY91eX6deN9pZuy8T1X2fZ/0X9IRcjomVb9v2vrH2vqeFnVyT
pXjfs31mP9v8679nX+n+Z/NfpP3LvT8K3Gy+pXWFpbm5Lb6g2ZDW42JhxZIHv9XFs/sK8sn61e/6
v5uMPp51f2Go9hZmOb0/HfZ/wTLsmt1233+l/g7PoJZ/6H6wdKyXasurysFoHPqWtp6gx7v+C9Hp
GS135/qvo/R/zj6tZV83p3T+oVCnPxqcuprt7a7622NDgC0PDLWubv2ucg39H6fdSyltTaG1uxi0
0taw7cO1uZh4/wBH+j12s/mvzGWW+l6aTOh9FrwrMCvp+MzCudvtxW01ipzht99lAZ6T3/o6/wA3
/BpYvQ+i4bXsxOn42O2xzHvbVTWwOdU71cd7xWxu59Fv6Sn/AET1O7pPSr72ZN+Hj25FdnrV3PqY
57bIrZ6zLHN3tt2Y+O31Pp/oKf8ARJXdJ6VfezJvw8e3Irs9au59THPbZFbPWZY5u9tuzHx2+p9P
9BT/AKJK7pPSr72ZN+Hj25FdnrV3PqY57bIrZ6zLHN3tt2Y+O31Pp/oKf9EiuxMV7L6301uZlT9p
aWgi2Wtod67Y/S7qWMp/Sf4L9GhY/SelYuLZhY2Hj0Yl+71seupjK37x6dnqVMaK376xsfu/MSxu
k9KxKDjYuHj0Y5sbcaaqmMZ6jSx9d3psa1nqsfVU5ln0/wBFWiuxMV2/dTWfUsZdZLQd1lfp+jc/
T3W1ehR6dn02ejV/o0ZZPU/03WujYzdH02X5ziePTqof097G/wDC+t1fGc38z0mX/pP5tlussnrX
6tldO6o3T0cgYl8audTmlmIKmNd7P+Uv2ZkWP/nGUY1vp/6C/WSSSSSSSSSSSSSSWT9bP/Er1n/w
hlf+ebFwH/5if9f/ACwX/9LV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJJJJJJJJJJLJxP8AKfUn
9Qd/Ren2XYuE3kPsbtozc17XfQtouryem43sreyr7dZ6t+P1Gv0tZJJJJJJJJJJJJJJJJJJJJJJZ
PTf8nZruin+jmt+V053cV+pGVhbW+xlXTX5GKzF/mWfY8nHxaav1G++zWSSSSSSSSSSSSSWT179L
Z0rCdpVl59fqEfSH2Zl/V6dn5vuyenUMs/4D1f8ACfpWayhdTVfU+m5jbarWlllbwHNc1w2vY9jv
a5jmrP8Aq7da7pbMbIe6zKwHOw8h9hJse7HPosyrg/3sfn0Np6g1r/8AA5df6W7+es00kkkkkkkk
kkklk9a/TZnScH6bLsv1sioc+njV25dVztvvZVR1Ovpm6z6Hqvox7f6R6Vq+sX6GjE6iOenZdNxJ
+g2uwnp+bdf+7VjYGdlZPqbmMp9H1rv0NdjFrJJJJJJJJJJJJLJwP1nrvU8p/wD2i9LAqYddv6Ov
qWRfW7/Bfavt2LTdU36f7OosfY/9HXRrLJ+tXs+r+bkj6eDX9uqHY2Ybm9Qx2Wf8E+7Grbdt9/pf
4Sv6a1kkkkkkkkkkkkkklk/Wz/xK9Z/8IZX/AJ5sXAf/AJif9f8AywX/09X/AB1/+JXF/wDD9f8A
55yl6AkkkkkkkkkkkkkkkkkkqnVc79ndNyc0M9Z9FZdVRO022fRx8Wsw/wDS5Nxrx6drHv8AVs+g
l0nB/ZvSsPp2/wBX7Hj1Y/qRt3ekxtW/ZL9m/Z9HeraSSSSSSSSSSSSSSSSSSSSSSyfrN+h6VZ1R
n890ic+rz9Fln2ij939bwn5WH6rmWfZ/tH2hlfq01rWSSSSSSSSSSSSSWTn/AKb6wdKxnaMprys5
pHPqVNp6exjv+C9Hq+S535/qso/SfzjLdZJZNf6j9YLmO9uP1atttR7HLob6OSHvf/hcjAbhfZqK
/wDBdNzr/Tq9O2y7WSSSSSSSSSSSSWT0/wDX+q5PVDrTi78DC89jx+1L/wA136XNx68P0rWez9l/
aMez0s1aGXi0ZuLdh5LfUx8mt1VzJI3MeDXY3cwte3cx35qq9Cyr8jptbMx2/Pxf1bPMBpN9Xsut
9NoZsqyv6Zi/o6vUw8jHu9Kv1VoJJJJJJJJJJIOXlUYWLdmZLvTx8at1tz4J2sYDZY7awOe7axv5
qq9Bxb8XpjG5LfTyL7Lsq6mQ7035V1udZjeowllv2Z+R9n9Zv896fqrQVTq2D+0ulZnTt/pfbMe3
H9SN231WOq37JZv2b/o70uk537S6Vh9R2el9sx6sj053bfVY23Zvhm/Zv+lsVtJJJJJJJJJJJJJZ
P1s/8SvWf/CGV/55sXAf/mJ/1/8ALBf/1NX/AB1/+JXF/wDD9f8A55yl6Akkkkkkkkkkkkkkkkkk
snrn6e/pnThqMjLZdcG/TbXiB3UGXD92r7fj9Pxr7HN2frfo/o7r6HrWSSSSSSSSSSSSSSSSSSSS
SSSSWT9VvZ0LFxefsHqYG/8Af+xWWdN9fb+Z6/2X1vS/wXqen6ln84tZJJJJJJJJJJJJZOT/AOKr
p3/hDO/8/dKWskqPWMK3MwiMYtZm0OF+FY+Q1t9furFj2B1rce/3YuZ6X6S3CvyaP8KjYWbVm1F7
A6uyt3p30WQLKrAA51NzWlzd+1zHtcx76bqX15GPZdj3VWvsJJJJJJJJJJLM6xdbkNPScJ7m5eS0
etbWS12Pjvd6d+V6zf5jIdU2+vpn0/Uzff6L8bFzbKNCmmqiplNLG1VVNDK62ANa1rRtYxjG+1rG
tU1k5P8Akzqoz+MLP9PHywPzckvZj9PyfTbt/pPrfYcu79Nd+j6V/N4mNkW16ySSSSSSSSSSybv8
p9WZQ3XD6VZvygdA/L2V3YVGx0+rVjU5H2+z2ezM/ZlmNd6uPlV1aySSyfqn/wCJXo3/AIQxf/PN
a1kkkkkkkkkkkkklk/Wz/wASvWf/AAhlf+ebFwH/AOYn/X/ywX//1dX/AB1/+JXF/wDD9f8A55yl
6Akkkkkkkkkkkkkkkkkkslv6f61Wb9PsGBX6Ud/tt1v2j1P6n7GxfR2/6S/f6n6P0tZJJJJJJBxM
qjNxaczGd6mPk1ttpfBG5jwLK3bXhr27mO/ORkkkkkkkkkkkkkkkklk9E9ub1upulVeePTYNGt9T
Fwcq7Y36LfVyb78iz9++623+csWskkkkkkkkkkkksnJ/8VXTv/CGd/5+6UtZJJZmfTbg2u6phMc8
ucz7fjMBd6tctqflMrZuf9tw6Pf+hZZdnY9P2D0brf2fZh6FN1V9TLqXttqtaH12MIc1zXDcx7Ht
9rmOappJJJJJJJKp1PO+w4rrWM9fJfLMTFB2uuuIc6rHY6H7N+z9Jbt9PGo9XKv/AFem16WDg/Zt
91z/ALRm5EHIyCNu7bPp1VVy/wBDEo3v+z4+/wBn6S22y/Lvycm+2kg5eLRm4t2Hkt9THya3VXMk
jcx4NdjdzC17dzHfmqr0/Kvbfb03Oduyafdj3OAaciiGfrWxg9L1abbPsuYyn/C+llfZ8THz8Sha
CSSSSSSSSo9TzbcdtePiBtmflODaK3SQG7mNycy1jSz9XwqrPWs/S0es/wBHC9evJy8dGwMKrAxW
41Rc8Bz7H2PgufZa92RkXP2hjN919tlu2pldP+hrrq9isJJLJ+qf/iV6N/4Qxf8AzzWtZJJJJJJJ
JJJJJJZP1s/8SvWf/CGV/wCebFwH/wCYn/X/AMsF/9bV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJ
JJJJJJJJJLJ6N/yj13/w+z/2x6atZJJJJQuFpqeKXNZaWkVve0vaHR7HPra+p1jGu/M9Wv8A4xc5
iB+JlUnKOfg5j7GssvyrnZeHkFxDL62eld9jwfXscz7A9+L0S37RZj04uJ6X2npiFQ/KzOhfVJj8
vIrdneiMu2uwtstaen5eRayy7+c/TWV++z+fY/8AT0W05LKr69PGrPTetUdOotusxcvGyMhzci2z
Ic2zHsw6muqvyn3XtZczN/S1Ot9H9DT6DKf1n7Rd6pd6GBbZ9o+yfRb64Z6rxuc1m3Hp93q5du70
sNnp3/rT6f1XK/o1uFiX5WD1Xp9NWF1HEoz7n0XnqGUzLYdtGTmVmn/KHUcijIa/F/M9PHspsv8A
tHqXfZPRqdRzcrG6fk9axKuo51+PTZks6ky5jMCz02uednSrs9rf2Ztb6O+vBtyLsX9cxMvJyn09
St2Otn1cpmNGXl7axZ9g6dZ9msbJcz7Xl5v2rA/RO2+jiYv2ir1X/a7fRzfs+/p0/q3mZV9edj5F
d1P2DJ+z0syXMfeKzRjZbG5F1FuTVc9n2rZXb61lz8f0ftT7cv17bFk1nqXWr+nX23V4uJjY+Q1u
PbZjudZkWZlTnW34r6b3MpZhfoqm2+j+mu9dl36t9nhmsysVuB0v7VY+jPy3Y/qyRkMx24+Tm+h9
r3Osfb6mJ9n+2/0v7JZ/O/tH/KSTsYdH6h05mJbkPq6hkPxsivJyLskQ3Hys2u2o5lt9lNrLMT0/
0T/Ssqut9eq2z7NZj4+LjZDPqr0nqzeoZp6llN6a1+S7Ie8AZdmLi3fqVpf01724+S9ldl2Fa/f+
s3erl/rC2MfGHTev42HjW5DsfKxMm25mRkXZMvoswa6HMdm25D6drMzI3ej6fq/4Xf6VWzbSSSSS
WTjf+KrqP/hDB/8AP3VVrJJJJJJJJJJJJLJzf0X1k6Xe/SqzHzMRjuZusOJm11QPd7sbp2bZv/m/
0P8ApLKt+skkksy7ptuHa/L6LXTXbc4uysR5NVF7nGXZL7Ka73UZrXf9qm0Xfaq/1fKZZ+qZGDYw
ep4udvZU7Zk0QMrEeQLqXOnazIqa5+zfsd6Vn8xk1/p8W27H2Wq2kkkkkks/K6rF7sHpra83qNcG
2g2bGUtID2vzrmMyH43qsP6tX6Fl+T/g6vs1WVk40sLpdWPacy/bk9SsbtuzC0B20kO+zY/03Y2E
xzf0WK2z/hr35GXZflXXkkklXzen4WfUKsyltzWO31k6OY8AtZfj2ti3HyK936LIpfXdV/g7FR/a
N/SvZ1p9Ywx7auqlwY0n80dSr2VU4Vr/AObrvrf9jyr/APyvtyMPBs1kkkkkkln5XU917undNdXf
1FseqCdzMZrgHtvzmsc17dzHfq2Jvrvzv8H6WN9qzcQuD0zFwd76m78m+DlZbwDdc5s7X5FrWs37
N7vSr/mMav8AQYtVOPsqVtJJBy8qjCxbszJd6ePjVutufBO1jAbLHbWBz3bWN/NVX6vYt+F0DpmH
kt9PIxsSiq5kg7XsrZXY3cwuY7a9v5q0Ekkkkkkkkkkkklk/Wz/xK9Z/8IZX/nmxcB/+Yn/X/wAs
F//X1f8AHX/4lcX/AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSyejf8o9d/8Ps/9semrWSSSSULqar6
n03MbbVa0ssreA5rmuG17Hsd7XMc1Z9PRA21hyM3JzMelwfRiZBrdWxzDND3WMpry8p+P/gvt2Tl
fptmVZ6mZVTkV18n6u7sPo2Bi32U09IsaRcH7btlWLk4VD2Oaz0rLfVuofZXbX9lur9Wu6qyr9Xs
u4XSxjWnIvybs/KLfTbkZHphzKyQ91NTMWnForY97d9rm0+tf+h9eyz7PjejM9Nofh2YeQ6zJqss
faXWvJe0vsdlV+lazZZT9ksc37E+v9Li+jR6VnqVb1Ub0Am+jJyuo5eZdiWC3GdaaWCskOru/Q4m
NjY932jHssx3vyar7aarLPsdmLb+lUbvqzj3VPwn5eSOlWNLHdLY5jKNjhrQy6qpnUa8f/uvXn+i
yv8AVPT+w/qqsZHSDb6dtWZkY2YyttVmbUKfUtY3Xbk1249uG/8ASOdaz9VZ9nfZd9l9CrIyK7YY
/Qqsdtwrysndk3U5ORYbAXvupdW59rn7PYzMqopxcnFq9PD+y1+hiY2L+kRc3pYybRkUZN2BlBvp
uyMf0y59YJe2m1mVTlUWMY92+pzqfWo/TehZX9oyfWj+xMX7L6O+z1/U+0fbpH2j7RHp/bPU2+n6
vp/ofS9L7J9k/wAn/Zv2d+qJYvSDVe3Iy8zI6jbVP2c5IpAqLgWWWVV4ePiV+q+t3p+ta222ur1a
qPSryMn1kzomKzpOH0kPs+z4P2X0nSN5+xvpvx/Udt2e9+NX621n/basPwqn9QpzyXerj020MaI2
lt7se2wuEbt+7Dq2e7/SKwkkkkksnG/8VXUf/CGD/wCfuqrWSSSSSSSSSSSSWT1v25vRLXaVV559
R50a31MXOxad7vot9XJvox6/377qqv5yxaySSSSqZ3TMXO2PtbsyaJOLlsAF1LnRufj2ua/Zv2N9
Wv8AmMmv9BlVXY++pVPW67gey2j9r08MtxzXTkj937Tj5VmPhW+1u67Lx8rH33WbKulU1fpEv+dH
RWa5N1mCztbnUX4dZP8Ao2ZHUKcal9v53ots9XZ6n+jer2F1Hp/UKjdgZNOXU12x1lFjbGhwAcWF
9TnN37XNVhUc3rnRen2inP6hjYlrm72133V1uLSS0PDLXtds3Ncq/wDzjw7fbg4+XnPd/Nejj2Nr
sHPqU9Qy243TH1bP0ld3230r2f0f1fUq3r7P1nqOuXZ+zMR3/abHcHZL2n83Jzv5vF31v9O6jp7P
XouZ62J1pL9qfVvpH+S6Lcei2j6PTMRofcN/6Y+l03Ca/J+i/wC0P9PH/m/1j+b96X7f9X+g9Nz8
yP5z9B9l2z9H/ll/TPW3+7+jev6f+G9P9F6i/bPUf/KLP/z8H/5JJftzJr9+V0fPx6R9O3bRft/d
/V+m5Wbm2bne39Di2/v2fovUsU6frJ0Sy1lD8puNk2uDasbLa7FveXHaz0cXObj5FrLH/o67K6tl
ln6P6bFppJLJ/Z/Uun/8kW12Yo+j03K9lbB+bXhZlDLLsSpu5z/Rvx+o1bPSxMP9n46X/OKinTqO
Jl9OPJN1Jsraz/T3ZvTznYGNU33ep9pyqfRYz1rvTp2WKxhdc6L1C004HUMbLta3e6ui6uxwaCGl
5ZU9ztm5zVeVfN6j0/p9Quz8mnEqc7Y2y+xtbS4guDA+1zW79rXKj/zm6ZZ/QxkZ+7Sp+Jj3W02O
/cq6gyv9m/T/AET7LMyuiiz+kW0+nYl9n6z1HXLs/ZmI7/tNjuDsl7T+bk5383i763+ndR09nr0X
M9bE60tDFxMXCobjYdNeNj1zspqaGMbJL3ba6w1jdz3bkZJJJZP1r1+rHVaxq+7Eupqb3fZax1GP
TW38+2+6yummtvvttf6a1kkkkkkkkkkkkkklk/Wz/wASvWf/AAhlf+ebFwH/AOYn/X/ywX//0NX/
AB1/+JXF/wDD9f8A55yl6AkkkkkkkkkkkkkkkkkksnpHs6p1yt3te7Lqua06E1uxMKhlzW/6J92N
k0ts+h6uPfX/AIKxaySSSSSSSSSSSSSSSSSSSSSSSSwf2j0/D691PNzMmnFxWU4eCbr7G1N+0M+2
Z78cOuczc/7Jn4t3/XP+Cu9Ox/zs+qv/AJc4H/sVT/6US/52fVX/AMucD/2Kp/8ASiX/ADs+qv8A
5c4H/sVT/wClEv8AnZ9Vf/LnA/8AYqn/ANKJf87Pqr/5c4H/ALFU/wDpRL/nZ9Vf/LnA/wDYqn/0
ol/zs+qv/lzgf+xVP/pRL/nZ9Vf/AC5wP/Yqn/0ol/zs+qv/AJc4H/sVT/6US/52fVX/AMucD/2K
p/8ASiX/ADs+qv8A5c4H/sVT/wClF57k/wCObqGF1rOx34eNndPputqxX0PdW5zW2baLzkTl02sf
S3/B0s3/AE11fR/8aX1P6o4VuyndPtc4tazNaKwQ1vqeochjrcStjvoN9XIY/f8A9bWr9YrqrehD
Nqe2zFpuxM59zCHN+z4+Rj5+RkMc2fVYzEpsu/Rfzv8AgfUWwkkkkkkkqOb0PovULRdn9Pxsu1rd
jbL6a7HBoJcGB9rHO2bnOVf/AJp/VX/ymwP/AGFp/wDSavYXTun9PqNOBjU4lTnb3V0VtraXEBpe
WVNa3fta1QzupUYWxjm2XZF0+hjUMNljy2J9rfZVU176q7MrJfRh0Puq+0ZFPqKp9h6l1L39Qvsw
8V2rcDFd6VgH5rc3qND3XOtbtZbt6bbh1VP9XGsv6nj/AKV+hi4mLhUNxsOmvGx652U1NDGNkl7t
tdYaxu57tyMkkoXU1X1PpuY22q1pZZW8BzXNcNr2PY72uY5qzP2F9j93Q7/2b/3V2erhn/0A30/Z
vpWWf5NvwPWyH+tmfakbF6tvvbh52PZg5j5DGP8AfTaWgud9kza/0Nu7ZdZXj2/Zuo/Z6X5FuBRU
tBJJV83p3T+oVCnPxqcuprt7a7622NDgC0PDLWubv2ucqP8AzT+qv/lNgf8AsLT/AOk1Ywuh9F6f
absDp+NiWubsdZRTXW4tJDiwvqY12zc1qvJJJJJJLJ+sP6WvAwm6W5efjemT9EfZn/te7f8Ane7G
6deyv/h/S/wf6Vmskkkkkkkkkkkkkksn62f+JXrP/hDK/wDPNi4D/wDMT/r/AOWC/9HV/wAdf/iV
xf8Aw/X/AOecpegJJJJJJJJJJJJJJJJJJLJ/mPrV+9+0cD4bPsN3/gn2j9t/yPS+zf4X1v0Wskkk
kkkkkkkkkkkkkkkkkkkkkuX/AObfRPrG/qdnVcVuXjHqLnYlhc5jgacfF6Zl7X0uqvYz7Zg5FL63
ey70K7v0jPQtUP8AxrfqJ/5Wf+D5H/vQl/41v1E/8rP/AAfI/wDehL/xrfqJ/wCVn/g+R/70Jf8A
jW/UT/ys/wDB8j/3oS/8a36if+Vn/g+R/wC9CX/jW/UT/wArP/B8j/3oS/8AGt+on/lZ/wCD5H/v
Ql/41v1E/wDKz/wfI/8AehL/AMa36if+Vn/g+R/70Jf+Nb9RP/Kz/wAHyP8A3oS/8a36if8AlZ/4
Pkf+9C89yf8AFJ9ZsnrWdXh49OF00XWuw7b7g5pq9SMeseicrK3+if8ADV/8Z+kXVdH/AMS/QcVw
s6pk3dSc1xPptH2eotLdrW2MrdZkb2P/AEm+vLq/4v8A0nYY31a6DidPv6di4NOPi5VP2fIbU3Y6
yva6rbfezbfa/ZY/9LZb63v+mp9Ayr8vo2JblO35jaxVmmAP1mk/Zs9vsDa/ZmVXs/Rfof8AQ/ol
oJJJJJJJJLPysq/Ivd0/p7tlrI+15cBwxw4B7a62vDq7eoW1u300v/RY1X65mfo/smJ1AuD0vA6f
vOLVttuj1r3udbdZtn0/tGXe63JyPSa7ZV61r/Sr/R1/o1bSSSSSSQcrExc2h2NmU15OPZG+m1oe
x0EPbursDmO2vbuVKm63plrMTLe63CtcGYmW8lzmOcdteFm2O9znud+jws2z+lf0TL/yh6F/VNNJ
JJJJJJJJJJZNP639ZL7xrV0vHGIxw0/TZJrzc2qwO9zvSxqOk2UvZ+j/AFq/+ds/o+skkkkkkkkk
kkkkksn62f8AiV6z/wCEMr/zzYuA/wDzE/6/+WC//9LV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJ
JJJJJJJJJLJ+sX6GjE6iOenZdNxJ+g2uwnp+bdf+7VjYGdlZPqbmMp9H1rv0NdjFrJJJJJJJJJJJ
JJJJJJJJJJJJKF11VFT7rntqqqaX2WPIa1rWjc973u9rWNas/wCrdNtfRMV97HVZOS12Xk1OBaWX
5TnZ2VTsd762VZGRbXXXZ+krZ/Ob3rTSSSSSSSSSSSSSWTh/qXXMrBHtx82sZ2M3t6gd6HVGVNb7
Kqmvf0/L9zd92Z1DMv8AUu/S+hrJJJJJJJKpnZ32bZTSz7Rm5EjHxwdu7bHqW22Q/wBDEo3s+0ZG
z2fo6qq78u/Gxr103B+xUOa9/rZF1j78m+NpfZYdztJe9tVTNmNi12W3Pow6MfH9Wz0VbSSSSSSS
SQcvFozcW7DyW+pj5NbqrmSRuY8Guxu5ha9u5jvzVV6flXtvt6bnO3ZNPux7nANORRDP1rYwel6t
Ntn2XMZT/hfSyvs+Jj5+JQtBJJJJJJJJJJZP1b/S4FnUT7ndTyLcttnHqUud6XTLdn+D/wAk04Hs
2Ms/7kfrPrLWSSSSSSSSSSSSSSWT9bP/ABK9Z/8ACGV/55sXAf8A5if9f/LBf//T1f8AHX/4lcX/
AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSDl4tGbi3YeS31MfJrdVcySNzHg12N3MLXt3Md+aqvQMq/
L6NiW5Tt+Y2sVZpgD9ZpP2bPb7A2v2ZlV7P0X6H/AEP6JaCSSSSSSSSSSSSSSSSSSSSSSyeu/rno
dDb/AN6W/wC1eWHVs+3/ALv9J9ajpv6OxmRT9v8AtlP9FWskkkkkkkkkkkkkksnr36t9j6qNPsGQ
31yPbONf+p5fq3f4PExfWq6pkb/0P+Ta/U9P+kU6ySSSSSSSqY32DLuPUaP0lrPUxPUO72+ja+rJ
qrZZ7a/1mn9M+tn6z6FH87XRjq2kkkkkkkkkkqme2ipn7SfRZfdgV22VNoBNzgW/pMepjXM9f19j
P1az9FZkV49n87TTZXYpuqvqZdS9ttVrQ+uxhDmua4bmPY9vtcxzVNJJJJJJJJZPXf1z0Oht/wC9
Lf8AavLDq2fb/wB3+k+tR039HYzIp+3/AGyn+irWSSSSSSSSSSSSSSSWT9bP/Er1n/whlf8Anmxc
B/8AmJ/1/wDLBf/U1f8AHX/4lcX/AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSSyf8Ak/rvhjdZ/DMo
r/tPd9s6bj/8Fj4/7J/7kZy1kkkkkkkkkkkkkkkkkkkkklC66qip91z21VVNL7LHkNa1rRue973e
1rGtWf0im223K6rkMdXbmuDKa3gtczFpL24bHsOx2+51uR1D9NVXlUfbvsV/9EWmkkkkkkkkkkkk
kkoXU1X1PpuY22q1pZZW8BzXNcNr2PY72uY5qz+i3W1Nf0nLe6zL6e1v6V5L3W473W14GVZcf5zI
tqx315m70/12nJf6P2azGst00kkkklR61m24HS8jJxw1+UGivErfJa/ItIx8Kl+0s9l2XbTVu31/
y7K/po3TsKrp/T8bApLnVYlNdFbnwXFtbW1MLy0Nbv2t/dVhBpyqL7L6qnbn4tgqvEEbXlleSG+4
e79DkUv9ijm5+LgVC3Jc4B7tlbK2Ptse4gu2U4+O22+5+xj7XelX/M12XfzVb0sLPxc+o24znEMd
ssZYx9VjHAB2y7HyG1X0v2PZa31a/wCZsru/mrGKWNlUZdZtx3b2NssqJgj30vfjXt9wb9C6qxiW
NlUZdZtx3b2NssqJgj30vfjXt9wb9C6qxiWNlUZdZtx3b2NssqJgj30vfjXt9wb9C6qxiMkkkksn
6u/oaMvpx56dl3UgD6Da7COoYVNH7tWNgZ2LjentYyn0fRp/Q11vWskkkkkkkksnoX656/XHf96W
z7L5YdW/7B+7/SfWv6l+krZkU/b/ALHd/RVrJJJJJJJJJJJJJJJLJ+tn/iV6z/4Qyv8AzzYuA/8A
zE/6/wDlgv/V1f8AHX/4lcX/AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSDlZeLhUOycy6vGx6433Wu
DGNkhjd1lhaxu57tqzWZOF9aeiWW9Osc2i127BzXM09WhzbaMyvHe5lj2YufT/M5TKfWfjfzf2Wz
1LbvTc77bQ5z2ejkU2PoyaJ3FllZ2u1hj3VWs2ZOLZZVS+/Dvx8j0q/WVtJJJJJJJJJJJJJJJJJJ
JJZPVv17Kx+it1qs/WOodwMas+zGf9Jv+UcnbR6N9fo5nTqerVfzla1kkkkkkkkkkkkkkkkln9Ux
by+nqOE3fnYctbXIAsosdU7Oxf0hbX6tteOyzFf6lH65Rj+rkfZPtXq2sTKozcWnMxnepj5NbbaX
wRuY8Cyt214a9u5jvzkZJJJJZPXP0mT0fFfrTkZ7fVZ+96FGV1LH930m+nm4WLd7f9F6b/0XqVrW
XL/WjIZT1CsZGZTVU6kelRkdQyOktDt1nq21ZWHW9vUX2N9FluO//k/0abP+9FZ9nUrX+k7MzM3E
xbOq1V3usJqvZQ7o7Mq2nLbjt2YbPXd62c6llFeDZ62ZXZiej9pq0MTqPT6sXIfbkud0tmaaumdW
dY29lDX4bHPzP2lnOyGuZ9uszsGvIufk/rV/7N/mv0CsfVrNxTk5tDMn7Y7KyH342bo77VXTR06j
IyfVxmV4Lvs197MD9VroZ+r/AM3Zk15dyx8HJxay4Y+dd+2P2xcyvBNr2g47+pWMzXUdN/R0ZuP9
jfmXW5z6Mv7O/wC0frVX2DZiLBycWsuGPnXftj9sXMrwTa9oOO/qVjM11HTf0dGbj/Y35l1uc+jL
+zv+0frVX2DZiLBycWsuGPnXftj9sXMrwTa9oOO/qVjM11HTf0dGbj/Y35l1uc+jL+zv+0frVX2D
ZibXWeo4t+D0vLGS6jo+bc1+VltsfjAY78fIvxn2ZbXUX4bLMxuCz+do3vf9l/w/o2ULcro4txa3
dVuH1fc3JP2x+ZbXX9oacL7Pj1dZFtN+WzZb1F/pOzsn9N9qq/7zvRw1hMs6nldNxsnIyTimnqj6
XVZN9JsqpzMSjpd78jFtpty2fs+1vo5Ftlv2hlv2n1LfV9VF+rl2QbejWvvutd1fpT83NFtj7Guv
aenObZRVc99WGz9eyv0GGzHx/f8AzX6Gj0+oWThfovrJ1ShmlVmPh5b28zdYcvCstk+73Y3TsKvZ
/N/of9JZbv1kkkkkkklk9d/XPQ6G3/vS3/avLDq2fb/3f6T61HTf0djMin7f9sp/oq1kkkkkkkkk
kkkkkkklk/Wz/wASvWf/AAhlf+ebFwH/AOYn/X/ywX//1tX/AB1/+JXF/wDD9f8A55yl6Akkkkkk
kkkkkkkkkkkuH+v/APjDzfqvazDxenOffc3dVmZH9HIBZu9JtL/Vve3c+u2uyzEfR+ht/TU2sXlt
F/1g+vP1gw8HOzLMi7Is2tc7bsqZtBybqcYGjHZsx6PWsrp9L7R6X+lX0JiYtGFi04eM308fGrbV
SySdrGAV1t3PLnu2sb+cqXVKbca39tYrHW241LmZGKwEuyKAfW2VtZ7rM3Gc17un+p+j/WMvF/Qf
bvtePoU3VX1Mupe22q1ofXYwhzXNcNzHse32uY5qmkkkkkkkkkkkkkkkkkkqnU877DiutYz18l8s
xMUHa664hzqsdjofs37P0lu308aj1cq/9Xptel03B+xUOa9/rZF1j78m+NpfZYdztJe9tVTNmNi1
2W3Pow6MfH9Wz0VbSSSSSSSSSSSSSSSSSWS7/JPUmuGnTupWBhYNG0ZbvVsN7t3sZV1N/p0O2ur/
AMp+h+hvyeq5NzNZJJJJZPWf+Uehf+H3/wDtj1JaySDdi0X2UW2t3PxbDbQZI2vLLMYu9p936HIu
Z70ZJJJJJJJJJZON/wCKrqP/AIQwf/P3VVrJJJJJJKv1DNqwMK7MtDntpbIrZBe9x9tWPQxxb6mR
kWllOPV/hbrK60HpmFbjtsyMstsz8pxdfY2SA3c92Nh1PcGfq+FVZ6Nf6Kj1n+tm+hXk5eQrySSS
SSSSSSSSSSSSSyfrZ/4les/+EMr/AM82LgP/AMxP+v8A5YL/19X/AB1/+JXF/wDD9f8A55yl6Akk
kkkkkkkkkkkkkkoXXVUVPuue2qqppfZY8hrWtaNz3ve72tY1q81zbc3/ABn9UGDhB2L9U+m3brs0
tiy+0At/V/UHsf6VjvSr/wABTb9pzP0tmNhrV/xefUC36r5vUcrMe2697vs+Ha2QDj+y51u3e7a+
+3067KrGfoH4n6K62m7eu4SWZdTb0y1+XiMdbhWuL8vEYC5zHOO6zNwq2+5z3O/SZuFX/Sv6Xif5
Q9ejqmhTdVfUy6l7barWh9djCHNc1w3Mex7fa5jmqaSSSSSSSSSSSSSSSSr5ubVhVB7w6yyx3p0U
VwbLbCC5tNLXFrd+1r3uc97KaaWWZGRZTj022sr4uDlWXtzeqPrtyK5ONRUCKaNwLXlpsJfk5ex7
sf7c9lH6v/R8TC+0Zn2nQSSSSSSSSSSSSSSSSSSQcrFozKHY+Q3fU+JElpBaQ+uyuxhbZVbVY1tl
N1bvVpt/S1fpFV6ZlXt29N6i7d1GisE2wGtyWN2sdnUNYGsbue5n2vG/7Q32en/RrcLKy9BJJJZP
1i/Q0YnURz07LpuJP0G12E9Pzbr/AN2rGwM7KyfU3MZT6PrXfoa7GLWSSSSSSSSSSSSWT0r9L1fr
V79ba8inEY7iKa8bHza6oHt9uT1HNs3/AM5+m/0ddWzWSSSSSSWTT/lbPx+oM/5Owt78Rx/w9z2+
h9uqj3fZKcazKox3u/R5/wBrsyWVehRg5eUbq3X+jdF+z/tXLrxPtdnpUeoT7ndz7Z2VMn9LfZ+g
p/wti0Ekkkkkkkkkkkkkkklk/Wz/AMSvWf8Awhlf+ebFwH/5if8AX/ywX//Q1f8AHX/4lcX/AMP1
/wDnnKXoCSSSSSSSSSSSSSSShddVRU+657aqqml9ljyGta1o3Pe97va1jWrzfKyupf4zOpO6f091
mH9UcOwfa8uNr8p7Ye2utrx/bppf/R/6Zmfp/smIvQ+n9Pwum4VOBgUtx8XHbtqqbwBz39znud77
LH++x/6SxWEkklmXdPdg2vzuk0tDrHF+ZhM2sbkFx3PvZOyqvqf/AHYf7Mz+jZ1n9FzOn28LNqza
i9gdXZW7076LIFlVgAc6m5rS5u/a5j2uY99N1L68jHsux7qrX2EkkkkkkkkkkkkklRzepOotGJiU
OzM1zd/otc1ja2OJZXkZlz/5jHda3b+jZflW7L/smJlfZsj01hdLqx7TmX7cnqVjdt2YWgO2kh32
bH+m7GwmOb+ixW2f8Ne/Iy7L8q68kkkkkkkkkkkkkkkkkkkkq+bhVZtQY8ursrd6lF9cCyqwAtbd
S5wc3ftc9jmvY+m6l9mPkV3Y91tTw4Wba604OcG151bd/skV3Vghv2rF3Fztm5zG5OM577sK5/p2
etRdh5mXeSSULqar6n03MbbVa0ssreA5rmuG17Hsd7XMc1Z/1dutd0tmNkPdZlYDnYeQ+wk2Pdjn
0WZVwf72Pz6G09Qa1/8Agcuv9Ld/PWaaSSSSSSSSSSr9QzasDCuzLQ57aWyK2QXvcfbVj0McW+pk
ZFpZTj1f4W6yutB6NhW4PTq6by12S91l+SWSWevkWPzMoUbg1/2duRfb9n9T9J6Pp+p71eSSSSSW
T/y5/wCmb/28/wDlV/8AFX/01f8AKuss/rvQum9f6bZ03qVfqU2atcNH1vH0L6H67LWT/wCi7N9T
7K1xXQuu9S+pPUq/qt9abPU6ZZp0jq50YGD2tovc6dlTJaz3u/yf/L6e+i+n0VJJJJJJJJJJJJJJ
JZP1s/8AEr1n/wAIZX/nmxcB/wDmJ/1/8sF//9HV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJJJJ
JKF11VFT7rntqqqaX2WPIa1rWjc973u9rWNavN8rK6l/jM6k7p/T3WYf1Rw7B9ry42vynth7a62v
H9uml/8AR/6Zmfp/smIvQ+n9Pwum4VOBgUtx8XHbtqqbwBz39znud77LH++x/wCksVhJJJJJUc3p
VWVaMmu67DzGt2Nysdwa7aCSGW1WtuxMpjN9vpfbMbI+z+tdbjejc/1FX/amV072darmoa/tPHrI
xoOv6zR6uVk9P9JvqetkX+p05lNfr259Nl32SnTpuqvqZdS9ttVrQ+uxhDmua4bmPY9vtcxzVNJJ
JJJJJJJJBysvFwqHZOZdXjY9cb7rXBjGyQxu6ywtY3c921Z/2vqXU/b09lnT8X87Nyqdtjwfa5mF
hXuruotZ7/1nqWN6TH11eng9Rx7/AFKr2FgYuBUasZrgHu32Pse+2x7iA3fdkZDrb7n7GMqb6tn8
zXXT/NVsVhJJJJJJJJJJJJJJJJJJJJJJV83Cqzagx5dXZW71KL64FlVgBa26lzg5u/a57HNex9N1
L7MfIrux7ran18XOyq724XVGV1ZFkjGvqJNN+0Fzw0WAPxsvYx2R9he+/wDV/wCj5eb9nzPs2gkk
sm3/ACV1KzMd/Qep2UsujmvLdswaL3DV9lWaz7FhO9P+i20UXej6eTm5ONrJJJJJJJJJJLJyP8o9
ZrxB7sTpm3Iye7X5Lh+o4zvp1v8Aste/qF9Nmy6i/wDYuXStZJJJJQuuqoqfdc9tVVTS+yx5DWta
0bnve93taxrVmenldY0yqvs/SXaih5IuyW/mszqXsZ9kxP8ACPwt9t+XW+qnP+yfrvTsjWSSWf13
oXTev9Ns6b1Kv1KbNWuGj63j6F9D9dlrJ/8ARdm+p9la4roXXepfUnqVf1W+tNnqdMs06R1c6MDB
7W0XudOypktZ73f5P/l9PfRfT6Kkkkkkkkkkkkkkksn62f8AiV6z/wCEMr/zzYuA/wDzE/6/+WC/
/9LV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJJJJKF11VFT7rntqqqaX2WPIa1rWjc973u9rWNav
N8rK6l/jM6k7p/T3WYf1Rw7B9ry42vynth7a62vH9uml/wDR/wCmZn6f7JiL0Pp/T8LpuFTgYFLc
fFx27aqm8Ac9/c57ne+yx/vsf+ksVhJJJJJJJJZl3SLarX5HSsp2FbY4vspeDdivc4y978Nz6nUv
3Ptu/wAn5GD6+VZ6+b9rUP2xn4+nUel5FbW/zmRiFuXSJ+h6VdXp9Wu/MY//ACT+js/7rM+0q3g9
V6b1HeMLJrvfTHr1NP6SoumK8rHdF2Nb7Ht9HIrrt3seraSSSSSSz8rr/ScW92K+/wBXLrj1MTGY
/JvYCA8WW4mEzIyaqtrmfprKvS/SVf6WtB+39dyfZi9M+xdn259tftn6NlGP02zO+1el9K2m7K6d
v/Rsrv8AfZZQbF6TsvbmZ2RZnZjJLHv9lNRcC132TCr/AENW3fdXXkW/aeo/Z7n49uffUtBJJJJJ
JJJJJJJJJJJJJJJJJJJJBysTFzaHY2ZTXk49kb6bWh7HQQ9u6uwOY7a9u5Z+7qXSdHNs6l04aMLB
uy6Gj3brzZbv6nUxm5u6iv8Aaf6On9B1XJvuyWadN1V9TLqXttqtaH12MIc1zXDcx7Ht9rmOapqF
1NV9T6bmNtqtaWWVvAc1zXDa9j2O9rmOaszpuX9kvd0fPu/WBY/9nuud78jHj12ek55c++3BZvw8
n9Ldl/q1fUMv+nVLWSSSSSSSSWf1PqfobsHBdXb1i2suxcVxmJ3MZl5bGObZV0+qxv6e/wD9B8f1
cy3Hx7bGFhVYVRYwusssd6l99kGy2wgNddc5oa3ftaxjWsYymmllePj1049NVTLCSSSo5vVasW0Y
1dN2ZmObvbi47Q520kgPtttdTiYrH7LfS+2ZOP8AaPRuqxvWuZ6aFT0u3JtZlda9HJtqcH4uOxpN
GO4He2xnrbnZObW79H+0HMx/0f8ARcTB9fL+0aaSSSSz+u9C6b1/ptnTepV+pTZq1w0fW8fQvofr
stZP/ouzfU+ytcV0LrvUvqT1Kv6rfWmz1OmWadI6udGBg9raL3OnZUyWs97v8n/y+nvovp9FSSSS
SSSSSSSSSWT9bP8AxK9Z/wDCGV/55sXAf/mJ/wBf/LBf/9PV/wAdf/iVxf8Aw/X/AOecpegJJJJJ
JJJJJJJKF11VFT7rntqqqaX2WPIa1rWjc973u9rWNavN8rK6l/jM6k7p/T3WYf1Rw7B9ry42vynt
h7a62vH9uml/9H/pmZ+n+yYi9D6f0/C6bhU4GBS3Hxcdu2qpvAHPf3Oe53vssf77H/pLFYSSSSSS
SSSSSVTO6XgdQ2HKq3W0z6N7HOqur3R6n2fLodVk4/qtbst9G1nq1/o7P0aqfsD0v6D1LPw5/nP0
/wBq3R9H/llnU/R2e7+jeh6n+G9T9F6a/Z3XaP6L1f1t30/t+NXbEfR9D9mu6Ns/4X1vtP8Ag/T9
H9J6q/7KqP8AuB1Hd/x2Dsj/ANzf2j1P/Qb0tn+G9X9EvtP1q/8AK7A/9jrv/kUlt+tV/v8AUwMC
NPS9O7Nn/hPtHq9G2fu+j9ls/f8AX/SenUv2Z1q73ZPWbKXjQNwaKKq4/eezqDOr3er/ACm5LKtn
p/oPp2Wr/m9Xb7s3Pz8u0aCz7S/Ghv7no9I/Z2M73f4R9Hr/APC+n6WzQxcTFwqG42HTXjY9c7Ka
mhjGyS922usNY3c925GSSSSSSSSSSSSSSSSSSSSSSSSSSSSSWZd0d1Vr8npFzenX2uL76/SbZj3P
cfdflYzTRa7I9z/1jGysS679D9ssyqceqlKnrlTLWYvU6ndNyrHCusWkGi15OxjcPOb+gufc/f8A
Z8W37P1KytnrP6fStNBysWjModj5Dd9T4kSWkFpD67K7GFtlVtVjW2U3Vu9Wm39LV+kWf9uyule3
q9nr4h/m+oV1EbAPzepsq9Sun9H+ns6mxuN07+f9anp3p4/2vTpuqvqZdS9ttVrQ+uxhDmua4bmP
Y9vtcxzVNJJJJJZl3WG5Fr8LpJbk5bXGu26HPx8dzTtu+1X17anZFH/lZXf9ts307/suM+zNot4W
FVhVFjC6yyx3qX32QbLbCA111zmhrd+1rGNaxjKaaWV4+PXTj01VMsJJKvm9QwsCoW5lzaWvdsrB
1c95BcyjHqbNuRkWbf0WPSyy63/B1qj6nVuqa0GzpOH2tfWx2XaD7mW0V3G6nBq+h/T8W7Ms9S6m
zD6dbTXdbewun4WBUasOltLXu32Eaue8gNffkWum3IyLNv6XIufZdb/hLFYSSSSSSWf13oXTev8A
TbOm9Sr9SmzVrho+t4+hfQ/XZayf/Rdm+p9la4roXXepfUnqVf1W+tNnqdMs06R1c6MDB7W0XudO
ypktZ73f5P8A5fT30X0+ipJJJJJJJJJJJLJ+tn/iV6z/AOEMr/zzYuA//MT/AK/+WC//1NX/AB1/
+JXF/wDD9f8A55yl6AkkkkkkkkkkkoXXVUVPuue2qqppfZY8hrWtaNz3ve72tY1q83ysrqX+MzqT
un9PdZh/VHDsH2vLja/Ke2Htrra8f26aX/0f+mZn6f7JiL0Pp/T8LpuFTgYFLcfFx27aqm8Ac9/c
57ne+yx/vsf+ksVhJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJQupqvqfT
cxttVrSyyt4Dmua4bXsex3tcxzVmfsW/F16PnWYbB9DDtaMjEB+jpTYa8yiplftoxcHqGHh0enX+
r/z1dy/bj8T29ZxLMIjnIqDsnEjl9hzKamvxaqGFnr3dTxun1fznpetTTZer2F1Hp/UKjdgZNOXU
12x1lFjbGhwAcWF9TnN37XNVS7pFtVr8jpWU7CtscX2UvBuxXucZe9+G59TqX7n23f5PyMH18qz1
837WoftfqdHtzOkZHs1tvxLKcikN+lvqD7MXqV+xn066+mev6n6PHqyP0fqr/nT0Jn9KyvsE/Q+3
12YW/wDe9D9pV4vr7P8AC+j6npfo/U/nK0v+dn1V/wDLnA/9iqf/AEol/wA6vq+/TGza85/erB3Z
lgH+kfj9Pbk3Mq/N9Z1fpb/T/wBIxL9uX36dO6Zl5APtF1zBiVtf4XM6g7Hz/Sb7XWX43T8v2fzP
r3VvoS/Z/Vc/XqmT9lpP/aLAe9k/8f1SMfNt9zWW1fY6+l7P0mPkfbalp001UVMppY2qqpoZXWwB
rWtaNrGMY32tY1qmks/K6/0bEvdi25dbsxkThVE3ZOoD/bgY3q5j/wBG71fZR/M/pv5pB+0dZ6jp
iV/szEd/2pyGh2S9p/OxsH+bxd9b/Upv6g/16Lmejl9FVjC6PhYdpyQHX5r27LM28+pe5pIe+sWO
/mMd1rfV+x4raMKqz+YxqleSSSSSSSSSWf13oXTev9Ns6b1Kv1KbNWuGj63j6F9D9dlrJ/8ARdm+
p9la4roXXepfUnqVf1W+tNnqdMs06R1c6MDB7W0XudOypktZ73f5P/l9PfRfT6Kkkkkkkkkkkksn
62f+JXrP/hDK/wDPNi4D/wDMT/r/AOWC/9XV/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJKF11VFT
7rntqqqaX2WPIa1rWjc973u9rWNavN8rK6l/jM6k7p/T3WYf1Rw7B9ry42vynth7a62vH9uml/8A
R/6Zmfp/smIvQ+n9Pwum4VOBgUtx8XHbtqqbwBz39znud77LH++x/wCksVhJJJJJJJJJJJJJJJJJ
JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJUc3onSM+0X5mHTdksbtrySwC9gBLmfZ8psZGO
+t7vUqsptrfVZ+kr96r/ALJ6li/8mdTsazhuPnN+2VtB9znMtNmN1N9u/wDOyep5FTGepV6H8x6C
+2/WDG/pPTq8xg9ofg3t9Rx/0z8TqAwqcap8fzbep5ltL/Tq/WPfkJft/wBL+ndNz8Of5v8AQfat
0fS/5Gf1P0dnt/pPoep/gfU/S+mv+cvTv9Dn/wDuOzv/AHjS/wCcvTv9Dn/+47O/940v+cvTv9Dn
/wDuOzv/AHjS/wCcvTv9Dn/+47O/940v23mu91XRM+yo6ssnFr3NP0X+jlZ1GTVub/g8iim9n+Fq
rsS/7Kr/APuB07b/AMdnb5/9wn2f0/8A0J9Xf/gfS/Sr/m7i3/8AKl+R1btsy3j0S381lvT8RmL0
2/Y/9KyzIw7b/U/wv6Gj0tDFxMXCobjYdNeNj1zspqaGMbJL3ba6w1jdz3bkZJJJJJJJJJJJJZ/X
ehdN6/02zpvUq/Ups1a4aPrePoX0P12Wsn/0XZvqfZWuK6F13qX1J6lX9VvrTZ6nTLNOkdXOjAwe
1tF7nTsqZLWe93+T/wCX099F9PoqSSSSSSSSSSyfrZ/4les/+EMr/wA82LgP/wAxP+v/AJYL/9bV
/wAdf/iVxf8Aw/X/AOecpegJJJJJJJJJJLzzrVPXvrz17I6A1l3S/q30u4M6hc4bbMmxsWMZVu9r
mObsuxv8Cyn0uoZHqWWYWMu76f0/C6bhU4GBS3Hxcdu2qpvAHPf3Oe53vssf77H/AKSxWEkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
ln9d6F03r/TbOm9Sr9SmzVrho+t4+hfQ/XZayf8A0XZvqfZWuK6F13qX1J6lX9VvrTZ6nTLNOkdX
OjAwe1tF7nTsqZLWe93+T/5fT30X0+ipJJJJJJJJLJ+tn/iV6z/4Qyv/ADzYuA//ADE/6/8Algv/
19X/AB1/+JXF/wDD9f8A55yl6Akkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkksf624XQc3oOUz6wFtfT62+o+86Oqc
PbXdjuhzvtG52yprGP8AW3/Z/Tu9b0n+C3/Wnre3Cxa+oXW4fR7hb0wWtaC0sdux7LKv0zXvqaP0
VV1uSzGZ+r0/oV9BdA6zR1zo2J1bHG1mVWHFmp2PB9O+nc5te/0bmWVeps/SfTWgkkkkkkksn62f
+JXrP/hDK/8APNi4D/8AMT/r/wCWC//Q1f8AHX/4lcX/AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSr5vTun9QqFOfjU5dTXb2131tsaHAFoeGWtc3ftc5eefWP/ABMYGRN/1dv+xW6fqmQXPpP0G+y/
9Jk0+31bHep9r9Sz/QVoX+LF/Wfq11a76rddxbMQZ+7IwS4AsddWxjsllN9LbKr9+L6b7HfafTx/
s3pfz169QSSSSSSSWT9bP/Er1n/whlf+ebFwH/5if9f/ACwX/9HV/wAdf/iVxf8Aw/X/AOecpegJ
Ll/qx9WPq3f9W+k3XdJwrbbcLHfZY/Hqc5znVVue973V7nPc5aX/ADT+qv8A5TYH/sLT/wCk0v8A
mn9Vf/KbA/8AYWn/ANJpf80/qr/5TYH/ALC0/wDpNL/mn9Vf/KbA/wDYWn/0ml/zT+qv/lNgf+wt
P/pNL/mn9Vf/ACmwP/YWn/0ml/zT+qv/AJTYH/sLT/6TS/5p/VX/AMpsD/2Fp/8ASaX/ADT+qv8A
5TYH/sLT/wCk0v8Amn9Vf/KbA/8AYWn/ANJpf80/qr/5TYH/ALC0/wDpNL/mn9Vf/KbA/wDYWn/0
ml/zT+qv/lNgf+wtP/pNL/mn9Vf/ACmwP/YWn/0ml/zT+qv/AJTYH/sLT/6TS/5p/VX/AMpsD/2F
p/8ASaX/ADT+qv8A5TYH/sLT/wCk0v8Amn9Vf/KbA/8AYWn/ANJpf80/qr/5TYH/ALC0/wDpNL/m
n9Vf/KbA/wDYWn/0ml/zT+qv/lNgf+wtP/pNL/mn9Vf/ACmwP/YWn/0ml/zT+qv/AJTYH/sLT/6T
S/5p/VX/AMpsD/2Fp/8ASaX/ADT+qv8A5TYH/sLT/wCk0v8Amn9Vf/KbA/8AYWn/ANJpf80/qr/5
TYH/ALC0/wDpNL/mn9Vf/KbA/wDYWn/0ms36z/Vj6t0fVvq11PScKq2rCyH12Mx6mua5tVjmPY9t
e5r2uXUJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJLJ+tn/iV6z/4Qyv8AzzYl/wA0
/qr/AOU2B/7C0/8ApNL/AJp/VX/ymwP/AGFp/wDSaX/NP6q/+U2B/wCwtP8A6TS/5p/VX/ymwP8A
2Fp/9Jpf80/qr/5TYH/sLT/6TS/5p/VX/wApsD/2Fp/9Jpf80/qr/wCU2B/7C0/+k0v+af1V/wDK
bA/9haf/AEml/wA0/qr/AOU2B/7C0/8ApNL/AJp/VX/ymwP/AGFp/wDSaX/NP6q/+U2B/wCwtP8A
6TS/5p/VX/ymwP8A2Fp/9Jpf80/qr/5TYH/sLT/6TS/5p/VX/wApsD/2Fp/9Jpf80/qr/wCU2B/7
C0/+k0v+af1V/wDKbA/9haf/AEml/wA0/qr/AOU2B/7C0/8ApNL/AJp/VX/ymwP/AGFp/wDSaX/N
P6q/+U2B/wCwtP8A6TS/5p/VX/ymwP8A2Fp/9Jpf80/qr/5TYH/sLT/6TS/5p/VX/wApsD/2Fp/9
Jpf80/qr/wCU2B/7C0/+k0v+af1V/wDKbA/9haf/AEml/wA0/qr/AOU2B/7C0/8ApNL/AJp/VX/y
mwP/AGFp/wDSaX/NP6q/+U2B/wCwtP8A6TS/5p/VX/ymwP8A2Fp/9Jpf80/qr/5TYH/sLT/6TVLM
6H0Xp/Vuh3YHT8bEtdm2MdZRTXW4tOF1BxYX1Ma7Zua1dGsn62f+JXrP/hDK/wDPNi4D/wDMT/r/
AOWC/9LV/wAdf/iVxf8Aw/X/AOecpegJLJ+qf/iV6N/4Qxf/ADzWtZJJJJZ/7e6Z9q+y77N3qej6
3o3fZ/Un0vR/aHpfYfV9f9W9P7Tv+1/qn9J/RJO690wZ7+nNfZbl1WMqurqput9N1ja7ajkvoqsr
x6rK7m7L7310fz36T9XyPSr0/W3oV9TMim26zFsaHjLbjZBxw0jc59ub6H2SllP/AGp9W5n2TZaz
K9H0bVazesYODaKbvWstLd5rx6LslzWklrH2swqsh1LLHMs9L1tnreld6X8zahZvWGt6bTn4Jba2
7Jxcf3hwgXZVOBkMfWfTtqyKPVtZ6VvvoyK/Tvq9npoub1jBwbRTd61lpbvNePRdkua0ktY+1mFV
kOpZY5lnpets9b0rvS/mbVVwfrBVd0V3VbC26s5N2Pj/AGeHC2Muzp2A2lzn+lvyv1f9K+2vH32+
rvpoVfIszPtVdGf1mzByr9u3GwKa3U1iw7KGZWVnYud+luu342Nk3P6dV1Cyv0sXB+0eqxWOk9Rc
63GxXZDs+jPxnZ2Bmva1ljqmmj1GZVVdePVv/Xcd+NZVRVvp/Q30VXY32jNsYvXumZd7aKH2TbPo
WPpurptgF/6pl3VV4uXuqa++v7Ndb6uOx+RV+hZ6iWV17pmJe6i99k1R69jKbrKapAf+t5dNVmLi
banMvs+03VeljvZkW/oX+orGbn4uBULclzgHu2VsrY+2x7iC7ZTj47bb7n7GPtd6Vf8AM12XfzVb
0sLPxc+o24znEMdssZYx9VjHAB2y7HyG1X0v2PZa31a/5myu7+asYlm5+LgVC3Jc4B7tlbK2Ptse
4gu2U4+O22+5+xj7XelX/M12XfzVb0sLPxc+o24znEMdssZYx9VjHAB2y7HyG1X0v2PZa31a/wCZ
sru/mrGKpT9YulXWsrY+7ba4NqyHY97cd5cdtPpZ9lLcGxmQ4sZjWMyNmV6lX2f1PVrSv+sXSqMq
7EL7rsnGcG5FWPj35Dqy5jL6/VbiU3+my2q39FY/2W/pvT99F/pqn6x9HvtZXTc62u1wZXlMqtdi
uc47GMZ1Ntf7Pc91v6v/AEn+lfqv9I/RLTSSSSWT9bP/ABK9Z/8ACGV/55sWskkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkksn62f8AiV6z/wCEMr/zzYtZJJJJZ+V17pmJe6i99k1R69jK
brKapAf+t5dNVmLibanMvs+03VeljvZkW/oX+oq+J9YsVvQuldT6o9tFnU6aS1rGvcHX20/a/s9F
bPWtc9/p2Nx6v5y5/p0V+pfZWrFnXen1UU3vGR+sbvSpGNkG8hh2WWOwW0HNZUxxZuusx/S/S0f6
eneX9qYH2D9oer+rcTtdv37vR+z+ht+0fa/tH6t9j9L7V9q/VvR+0fo0LD690zNyhhUvsblmt132
e+m6iz02Gut13pZdVNnpepcxldn0Ln+r6X9Hv9OF31i6VTa+t77ttTi23Ibj3ux2Fp23ern10uwa
2Y7g9mTY/I2Yvp2/aPT9KxTzOvdMwso4Vz7HZYrbd9nopuvs9N5srbd6WJVdZ6XqUvZZZ9Cl/per
/SKPUk3rPTndPyOomxzMbEa92T6ldldlYrb61nrYtrGZVb/R/TNrfTvspfXbX7La1m52VmN2XdS6
lZ0ZlsupxcWqu2xlbY9W7qWRfT1Kn0qN1TsjJpqxMDp77/RvzMz9XyUXCzrMa/HqdmWdTxc7IuxK
77WMZdXk44yHX1OGPTiU24n6hks3+j61WRX/ANq8fK/UodD+teD1Dp/T7bnObfl00myxlFwxRfY1
m/HZnurdhb/tLvsvpfa/U+1fqf8ASv0aNk/WGnD61f0/J3FrMbHyKWUU233uNtmZVkPNOIy+37PV
9mxv0vo7KrL/ANLb+npUup9doxukM6rRZX9nORj1WWXSxrGWZNOFl+sH+k/HtxmWXeoy/Z9mvq/W
K/0dlasYXWMHOtNNPrV2hu8V5FF2M5zQQ176mZtWO65lbn1+r6O/0fVp9X+eqV5Z+L17pmXe2ih9
k2z6Fj6bq6bYBf8AqmXdVXi5e6pr76/s11vq47H5FX6FnqKWb1jBwbRTd61lpbvNePRdkua0ktY+
1mFVkOpZY5lnpets9b0rvS/mbVG7r/SaMWjLtv205Vhpo9jy91wFjzi+g1nrNy/1e6n7K+v7R9q/
U/T+1foUH/nP0j6O7I9bn7L9lyftOz/uR9g+z/bfsm79H9s9D7L636H1vVWhi5VGZQ3Ix3b6nzBg
tILSWWV2VvDbKrarGurupsb6tNv6K39IjJJJLJ6z/wAo9C/8Pv8A/bHqS1lk/Wz/AMSvWf8Awhlf
+ebFwH/5if8AX/ywX//T1f8AHX/4lcX/AMP1/wDnnKXoCSyfqn/4lejf+EMX/wA81rWSSSSXCdWy
G39AzMIdUsxOpPxLaWfVjErx3Ord6bq6+n1YgxL+pW1NZt35dFnoXUf5RxPsuB6Xo9H0C6q/M61d
S9ttVubU+uxhDmua7A6a5j2Pb7XMc1Zn/wCaz/2g/wDumrtXUen9H6l1UdVyacAZuSzIxXZFjam2
VjFw8R7qrLXNY99d+Lay2r+ep/Q2Ws9LIx/VpZH6XDzs6v3Yud1rpt2Lb2srbZ0fE9av/gn3Y13o
2fQvq/WKPUx7abX3auo9P6P1Lqo6rk04AzclmRiuyLG1NsrGLh4j3VWWuax7678W1ltX89T+hstZ
6WRj+rS6cH3dMwup012WU4XV+o5VtQY4Xek+7quJ7MV7W3erV9sZdZjbPtPp1211U25Xp41qpqzO
pdMzMHDrrysfqGRkXXdUF1bsbJofc/8AUmX478jN9V2F6PRbLXY1X7PpqtsxbrfsWHTk2w89Qv6h
l241d+Xi4jsarolltLrWi4evazP9F9+NT+13U4tdddrsiqvGxfX9T9ayserK6ln411NDh9YLM26v
Lw78vAYyhrKWVZOPkZduXjsxj1LpmJgsre+z9oZn6r6bKMzIst/nbt2bRVkX05XV3dCubdZ6HTMd
uNvta57315VNWTi5mR1DI6k97sj9Rb/PW/YPRs6hjZVlosK8Y31e6D6tzem1VYTcfL6qRWX41lbK
K7OnudlMtpw335VDq8mzLr9Gu7B+wen9vycN9Muk9RwsbqvVc+3qdnUMNuBRa3OtbWWuZjPzrM37
G/Ax8anNqwvtNH2h+MzI9G/I+z22er+hWn1S6rC61g9TzHtowasbKx7cmwhtbLLrMG2ht1jvbSy1
uJe1ttv6H1vTo3+vkY9doepPx+udF6w3pFbcqzJwrMarMr2ene813tqx6crd+mZj23e6z+i1XZFl
XrevXmV0C651vpHU+i9Q6XgZlN/Us3Gux6MFrx9oNtlb6m024joyMd9b3frP2iur7H+lsy/QrptV
3o3/ACj13/w+z/2x6asqj/xCdA/9ov8A7cdPXVpJJJLJ+tn/AIles/8AhDK/882LWSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSWT9bP8AxK9Z/wDCGV/55sWskkkkuf6b1XpvSKb8DqWT
XjZv2vMtZivP6axmRk5GXiuxKGzbmevVfX6f2Rl36xvxP6XVbSqnTP8Akf6k/wDWf/iXmq71rJrx
+ofrOa3oeNZSyOpgUB1z2utjBdkZ1V+PSzFY92Qymyv1sv7VY/E9NmFn+tldNa52Tfm1X3dRrwuq
tznWOY0X3YtnTv2WzMxqMenGZlY/rm70LcWj9dx8K/7F9syPZfp09Rrz/rVhOppyK6mYGaPUyKX4
+5xu6ZuYynLbTk/o27N1noeh+l/RW2WMv9GHQ+t9I6Z0Xp/S8/Mpo6lhY1OPfguePtAtrrZU6mrE
bORkPse39W+z12/bP0VmJ69d1Sh9VcW/Cym4eS308jG6L0qq5kg7XsPUq7G7mFzHbXt/NSsxb8o9
dZjt9S2rq+FkiuQC8Y1PR82yqsvLa/Vtrx3V0+o+ur1f522qv9Ilj5OZlZPVHdJHrPz7Gsp6mHVl
uEGUU1fZc3GyHjOry8LJ+15jOmfY/S9fM/WLMX7TmWUG6dUx+fg4F1deAOjY5OL003NtscQ37AzP
q2P+0fs/Hx3ZGJj25X6XLfl2fasPEuxcf1crE6r03N+oNPRcbJrs6rk9Ibi04ExkOtfjCmv9Vftu
bU7d6v2lzPs32T9e9b7H+nWrd1XpvTfrVmnqGTXiMtwMLZbefTrJbd1P9H9os20ttdu3V0us9W1j
LfS/mbtlLOtaOndR6mA5+HldY6dkY1jGuebaq7Oj4zrqKqw+65j7sW77P6df60z07sb1abqbLL9v
Uen9Y6l0odKyac8YWS/IynY9jbW11nFzMRjrbKnOYx9l+VUyqr+eu/TWVM9LHyPSsdb/AMqdE610
7B/TZbce7ENf0f01uOLaqt9myv315VHv3+n70h13oee+vEosrz8h1jC7DZtddUWObZ6+XjW7LML7
FYz1LPtTabachjKGfr32fHsr1dR6f0fqXVR1XJpwBm5LMjFdkWNqbZWMXDxHuqstc1j3134trLav
56n9DZaz0sjH9WlX+l6vi51fuxc7rTrsW3tZW3pFuJ61f/BPuxrvRs+hfV+sUepj202v1cb/AMVX
Uf8Awhg/+fuqpfVr/k67/wAP9R/9vsxaySSSyes/8o9C/wDD7/8A2x6ktZZP1s/8SvWf/CGV/wCe
bFwH/wCYn/X/AMsF/9TV/wAdf/iVxf8Aw/X/AOecpegJLJ+qf/iV6N/4Qxf/ADzWtZJJJJJJJJJJ
JZ+V9XugZt7snM6ZiZORZG+62it73QAxu6yxjnu2sbtVrFxMXCobjYdNeNj1zspqaGMbJL3ba6w1
jdz3bkZJJJJJJJJJJJJJZP1s/wDEr1n/AMIZX/nmxaySSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSyfrZ/4les/wDhDK/882LWSSSSSSSVfNwMXPqFWS1xDHb631vfVYxwBbvpyMd1V9L9
j31O9Kz+Zssp/mrHqGD0vDwN5xxY59sb7b7bL7CGz6df2jLsvu9KvfY6un1PSrfbb/pbFbSSVHN6
H0XqFouz+n42Xa1uxtl9Ndjg0EuDA+1jnbNznI2F07p/T6jTgY1OJU5291dFba2lxAaXllTWt37W
tVhJJJJJJJJJJJJJZPWf+Uehf+H3/wDtj1JayyfrZ/4les/+EMr/AM82LgP/AMxP+v8A5YL/1dX/
AB1/+JXF/wDD9f8A55yl6Akuc6HmdW6f0Xp+Bd0PNdbiY1NFjmWYRaXV1sqeWF3UGu2bm/uq7+2e
o/8AlFn/AOfg/wDySS/bPUf/ACiz/wDPwf8A5JJftnqP/lFn/wCfg/8AySS/bPUf/KLP/wA/B/8A
kkl+2eo/+UWf/n4P/wAkkv2z1H/yiz/8/B/+SSX7Z6j/AOUWf/n4P/ySS/bPUf8Ayiz/APPwf/kk
l+2eo/8AlFn/AOfg/wDySS/bPUf/ACiz/wDPwf8A5JJftnqP/lFn/wCfg/8AySS/bPUf/KLP/wA/
B/8Akkl+2eo/+UWf/n4P/wAkkv2z1H/yiz/8/B/+SSX7Z6j/AOUWf/n4P/ySS/bPUf8Ayiz/APPw
f/kkl+2eo/8AlFn/AOfg/wDySS/bPUf/ACiz/wDPwf8A5JJftnqP/lFn/wCfg/8AySS/bPUf/KLP
/wA/B/8Akkl+2eo/+UWf/n4P/wAkkv2z1H/yiz/8/B/+SSX7Z6j/AOUWf/n4P/ySS/bPUf8Ayiz/
APPwf/kkl+2eo/8AlFn/AOfg/wDySS/bPUf/ACiz/wDPwf8A5JJftnqP/lFn/wCfg/8AySS/bPUf
/KLP/wA/B/8AkkqXXMzq3UOi9QwKeh5rbcvGuorc+zCDQ6yt9TC8t6g52zc791dGkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkks/6w4t+b0DqeHjN9TIycS+qlkgbnvrfXW3c8tY3c935y
D+2eo/8AlFn/AOfg/wDySS/bPUf/ACiz/wDPwf8A5JJftnqP/lFn/wCfg/8AySS/bPUf/KLP/wA/
B/8Akkl+2eo/+UWf/n4P/wAkkv2z1H/yiz/8/B/+SSX7Z6j/AOUWf/n4P/ySS/bPUf8Ayiz/APPw
f/kkl+2eo/8AlFn/AOfg/wDySS/bPUf/ACiz/wDPwf8A5JJftnqP/lFn/wCfg/8AySS/bPUf/KLP
/wA/B/8Akkl+2eo/+UWf/n4P/wAkkv2z1H/yiz/8/B/+SSX7Z6j/AOUWf/n4P/ySS/bPUf8Ayiz/
APPwf/kkl+2eo/8AlFn/AOfg/wDySS/bPUf/ACiz/wDPwf8A5JJftnqP/lFn/wCfg/8AySS/bPUf
/KLP/wA/B/8Akkl+2eo/+UWf/n4P/wAkkv2z1H/yiz/8/B/+SSX7Z6j/AOUWf/n4P/ySS/bPUf8A
yiz/APPwf/kkl+2eo/8AlFn/AOfg/wDySS/bPUf/ACiz/wDPwf8A5JJftnqP/lFn/wCfg/8AySS/
bPUf/KLP/wA/B/8Akkl+2eo/+UWf/n4P/wAklXtt6l1DqXSielZOJViZL77rr34paGnFzMVoDcXM
ybnPddk1f4JbyyfrZ/4les/+EMr/AM82LgP/AMxP+v8A5YL/1tX/AB1/+JXF/wDD9f8A55yl6Akk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkksn62f+JXrP/hDK/wDPNi4D/wDMT/r/AOWC/9fV/wAdf/iV
xf8Aw/X/AOecpegJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJ
JJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJJLJ+tn/iV6z/4Qyv8AzzYuA/8AzE/6
/wDlgv/Q1f8AHX/4lcX/AMP1/wDnnKXoCSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSyfrZ/4les/+
EMr/AM82LgP/AMxP+v8A5YL/0dX/AB1/+JXF/wDD9f8A55yl6Akkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
kkkkkksn62f+JXrP/hDK/wDPNi4D/wDMT/r/AOWC/9Lr/wDGB0XpXWuhsxOp9Rr6SxuQyyjKtLAz
1A2xvpubc+n1N9L7vYy2t/8AhP8AB7Fi/wDjcfWr/wCfTP8Auu/970v/ABuPrV/8+mf913/vel/4
3H1q/wDn0z/uu/8Ae9L/AMbj61f/AD6Z/wB13/vel/43H1q/+fTP+67/AN70v/G4+tX/AM+mf913
/vel/wCNx9av/n0z/uu/970v/G4+tX/z6Z/3Xf8Avel/43H1q/8An0z/ALrv/e9L/wAbj61f/Ppn
/dd/73pf+Nx9av8A59M/7rv/AHvS/wDG4+tX/wA+mf8Add/73pf+Nx9av/n0z/uu/wDe9L/xuPrV
/wDPpn/dd/73pf8AjcfWr/59M/7rv/e9L/xuPrV/8+mf913/AL3pf+Nx9av/AJ9M/wC67/3vS/8A
G4+tX/z6Z/3Xf+96X/jcfWr/AOfTP+67/wB70v8AxuPrV/8APpn/AHXf+96X/jcfWr/59M/7rv8A
3vS/8bj61f8Az6Z/3Xf+96X/AI3H1q/+fTP+67/3vS/8bj61f/Ppn/dd/wC96X/jcfWr/wCfTP8A
uu/970v/ABuPrV/8+mf913/vel/43H1q/wDn0z/uu/8Ae9L/AMbj61f/AD6Z/wB13/vel/43H1q/
+fTP+67/AN70v/G4+tX/AM+mf913/vel/wCNx9av/n0z/uu/970v/G4+tX/z6Z/3Xf8Avel/43H1
q/8An0z/ALrv/e9L/wAbj61f/Ppn/dd/73pf+Nx9av8A59M/7rv/AHvS/wDG4+tX/wA+mf8Add/7
3pf+Nx9av/n0z/uu/wDe9L/xuPrV/wDPpn/dd/73pf8AjcfWr/59M/7rv/e9L/xuPrV/8+mf913/
AL3pf+Nx9av/AJ9M/wC67/3vS/8AG4+tX/z6Z/3Xf+96X/jcfWr/AOfTP+67/wB70v8AxuPrV/8A
Ppn/AHXf+96X/jcfWr/59M/7rv8A3vS/8bj61f8Az6Z/3Xf+96X/AI3H1q/+fTP+67/3vS/8bj61
f/Ppn/dd/wC96X/jcfWr/wCfTP8Auu/970v/ABuPrV/8+mf913/vel/43H1q/wDn0z/uu/8Ae9L/
AMbj61f/AD6Z/wB13/vel/43H1q/+fTP+67/AN70v/G4+tX/AM+mf913/vel/wCNx9av/n0z/uu/
970v/G4+tX/z6Z/3Xf8Avel/43H1q/8An0z/ALrv/e9L/wAbj61f/Ppn/dd/73pf+Nx9av8A59M/
7rv/AHvS/wDG4+tX/wA+mf8Add/73pf+Nx9av/n0z/uu/wDe9L/xuPrV/wDPpn/dd/73pf8AjcfW
r/59M/7rv/e9L/xuPrV/8+mf913/AL3pf+Nx9av/AJ9M/wC67/3vS/8AG4+tX/z6Z/3Xf+96X/jc
fWr/AOfTP+67/wB70v8AxuPrV/8APpn/AHXf+96X/jcfWr/59M/7rv8A3vS/8bj61f8Az6Z/3Xf+
96X/AI3H1q/+fTP+67/3vS/8bj61f/Ppn/dd/wC96X/jcfWr/wCfTP8Auu/970v/ABuPrV/8+mf9
13/vel/43H1q/wDn0z/uu/8Ae9L/AMbj61f/AD6Z/wB13/vel/43H1q/+fTP+67/AN70v/G4+tX/
AM+mf913/vel/wCNx9av/n0z/uu/970v/G4+tX/z6Z/3Xf8Avel/43H1q/8An0z/ALrv/e9L/wAb
j61f/Ppn/dd/73pf+Nx9av8A59M/7rv/AHvS/wDG4+tX/wA+mf8Add/73pf+Nx9av/n0z/uu/wDe
9L/xuPrV/wDPpn/dd/73pf8AjcfWr/59M/7rv/e9L/xuPrV/8+mf913/AL3pf+Nx9av/AJ9M/wC6
7/3vS/8AG4+tX/z6Z/3Xf+96X/jcfWr/AOfTP+67/wB70v8AxuPrV/8APpn/AHXf+96X/jcfWr/5
9M/7rv8A3vS/8bj61f8Az6Z/3Xf+96X/AI3H1q/+fTP+67/3vS/8bj61f/Ppn/dd/wC96X/jcfWr
/wCfTP8Auu/970v/ABuPrV/8+mf913/vel/43H1q/wDn0z/uu/8Ae9L/AMbj61f/AD6Z/wB13/ve
l/43H1q/+fTP+67/AN70v/G4+tX/AM+mf913/vel/wCNx9av/n0z/uu/970v/G4+tX/z6Z/3Xf8A
vel/43H1q/8An0z/ALrv/e9L/wAbj61f/Ppn/dd/73pf+Nx9av8A59M/7rv/AHvS/wDG4+tX/wA+
mf8Add/73pf+Nx9av/n0z/uu/wDe9Cy/8XHX/st32366Zf2T03faPWFnp+nB9X1vUz/T9L0/5zf7
Ni1f+b3QP/G6/Yf7Wr/Zfpx+1t9fp+p6/r+pv3eh6X279H6Prb9n6v6/rfpl/9k=

------_=_NextPart_000_01C08A62.62B5E5D0--

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 30 05:55:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03021
	for <sip-archive@odin.ietf.org>; Tue, 30 Jan 2001 05:55:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 21FF14433E; Tue, 30 Jan 2001 04:56:07 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from dogbert.isdn-comms.co.uk (unknown [212.56.122.225])
	by lists.bell-labs.com (Postfix) with ESMTP id 2BEAD44336
	for <sip@lists.bell-labs.com>; Tue, 30 Jan 2001 04:55:52 -0500 (EST)
Received: from isdn-comms.co.uk (dilbert.isdn-comms.co.uk [169.254.4.1])
	by dogbert.isdn-comms.co.uk (8.9.3/8.9.3) with ESMTP id KAA19452;
	Tue, 30 Jan 2001 10:54:37 GMT
Received: from isdn-comms.co.uk [169.254.128.4] by isdn-comms.co.uk (FTGate 2, 2, 0, 1);
     Tue, 30 Jan 01 10:54:31 +0000
Message-ID: <3A769F02.C4292075@isdn-comms.co.uk>
From: Chris Wayman Purvis <cwp@isdn-comms.co.uk>
Organization: ISDN Communications Ltd
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Dean Willis <dean.willis@softarmor.com>
Cc: Connie Blanchard <connie@ss8.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] adding a display name in From
References: <NEBBINLBBIOMPPIEAKHGKEGKCHAA.connie@ss8.com> <001101c08727$299ad0a0$ea036e3f@dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 30 Jan 2001 11:01:22 +0000
Content-Transfer-Encoding: 7bit

Dean,

Or, to put it another way, "kindof" NOT like ISDN (where caller ID and display
elements are often munged by networks).

Regards,
Chris

Dean Willis wrote:
> 
> Yep. Kindof like ISDN.
> 
> Some of the DCS authors proposed adding an authenticated-caller header at
> the proxy, using public-key mechanisms to provide for the integrity of the
> header through later hops.
> 
> --
> Dean
> 
> ----- Original Message -----
> From: "Connie Blanchard" <connie@ss8.com>
> To: <sip@lists.bell-labs.com>
> Sent: Thursday, January 25, 2001 12:37 PM
> Subject: [SIP] adding a display name in From
> 
> > According to the SIP FAQ, Caller ID is accomplished by using the "display
> > name" portion of the From header. But a proxy is not supposed to modify
> the
> > >From field. Does this mean that Caller ID will only be available if
> > initiated from the originator of the call?
> >
> >
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> >
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.

-- 
Dr Chris Purvis -- Development Manager
ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road
Winkfield Row, Berkshire.  RG42 6LY  ENGLAND
Phone: +44 1344 899 007
Fax:   +44 1344 899 001

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 30 11:16:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11680
	for <sip-archive@odin.ietf.org>; Tue, 30 Jan 2001 11:16:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E26994433E; Tue, 30 Jan 2001 10:17:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 3A77944336
	for <sip@lists.bell-labs.com>; Tue, 30 Jan 2001 10:16:07 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0UGFob03218;
	Tue, 30 Jan 2001 10:15:50 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: "Roy, Radhika R, ALCOO" <rrroy@att.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
Message-ID: <20010130101550.A11772@fdd.com>
References: <E5B80B001D76D211879C00E02910776107D67CA1@njc240po05.mt.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <E5B80B001D76D211879C00E02910776107D67CA1@njc240po05.mt.att.com>; from rrroy@att.com on Mon, Jan 29, 2001 at 08:40:29PM -0500
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 30 Jan 2001 10:15:50 -0600


Thank you two for the first non-comical name suggestion.
We are not in love with the handoff name, and if the SIP community
would let us title the method TRANSFER, we would be 
delighted.  

Supervised transfer encompases the conferenceing stage,
possible B2BUA'ing, and other things which is broader than our draft.
HANDOFF is the quick movement of one end of a two-party call leg.

We read the draft Pal Calhoun referenced:
ftp://ftp.isi.edu/internet-drafts/draft-manner-seamoby-terms-00.txt
It has an impressive number of definitions.  There seem to be
many kinds of handover/handoff.   Our draft is
the best map for a SIP-layer handoff.

We would like to wait for feedback at the Dallas interim meeting
before re-releasing it with a new name.

--
Rick

On Mon, Jan 29, 2001 at 08:40:29PM -0500, Roy, Radhika R, ALCOO wrote:
> TRANFER or similar term seems to be more acceptable to me/Radhika
> 
> -----Original Message-----
> From: Sean Olson [mailto:sean.olson@ericsson.com]
> Sent: Monday, January 29, 2001 2:35 PM
> To: Roy, Radhika R, ALCOO
> Cc: Patrice Calhoun; ???; Rick Dean; Rohan Mahy; sip@lists.bell-labs.com
> Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
> 
> 
> The name can be confusing, I agree. But as with all
> specifications, you need to read them in the appropriate
> context. I personally find HANDOFF completely apropos for
> this usage because it is a SIP method and because the
> introduction in the draft does a good job of establishing
> the scope and meaning of the method. If HANDOFF is
> taboo, how about "TRANSFER"? Nevermind the confusing
> part about the transfer draft defining REFER and the handoff
> draft defining REFER :)
> 
> my two cents
> /sean
> 
> Roy, Radhika R, ALCOO wrote:
> 
> > Yes, as PatC pointed out, the term "HANDOFF" is creating a constant
> > confusion.
> > I, like many others, also point this to the WG for consideration.
> > 
> > Radhika R. Roy
> > AT&T
> > 
> > -----Original Message-----
> > From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com]
> > Sent: Sunday, January 28, 2001 1:46 PM
> > To: ???
> > Cc: Rick Dean; Rohan Mahy; sip@lists.bell-labs.com
> > Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
> > 
> > 
> > Ahhh, I see that the misuse of terminology is biting this WG in the a..
> > 
> > This isn't a handoff as you, or I, or anyone else involved in mobility
> > management understands it. It is rather a form of call transfer. You are
> > correct that the handoff will occur at the GGSN/SGSN.
> > 
> > I have asked that the WG refrain from using the term handoff, or handover,
> > given that the mobility folks will have serious issues with it (as they
> have
> > had with SIP Mobility, when it fact it is really portability). However,
> the
> > WG
> > does not seem to be willing to listen to our requests :(
> > 
> > I suppose we will simply have to deal with the constant confusion we are
> > creating in the marketplace by abusing terminology.
> > 
> > PatC
> > 
> >> Dear all. 
> >> 
> >> I am some curious about HANDOFF method. 
> >> I think, HANDOFF method is required when SIP terminal moves from one
> > 
> > network
> > 
> >> to other network. 
> >> 
> >> In 3GPP TR23.821, the sentense,
> >> " As a consequence, the behaviour of the multimedia call control server
> >> (CSCF) can be the same whatever the access technology (radio or
> > 
> > wired-line).
> > 
> >> Multimedia call control/mobility management shall not be aware of the
> > 
> > access
> > 
> >> technology: the multimedia Call Control (CSCF) does not handle notions
> > 
> > such
> > 
> >> as Hand-Over, RA, "
> >> 
> >> It means that handoff is the problem of GGSN and SGSN not CSCF which
> > 
> > support
> > 
> >> SIP protocol. It is not the business of CSCF. 
> >> 
> >> Therefore I think HANDOFF method is not required at least 3GPP. 
> >> 
> >> What do you think about this? 
> >> 
> > 
> > 
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 30 12:13:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13047
	for <sip-archive@odin.ietf.org>; Tue, 30 Jan 2001 12:13:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 230954434C; Tue, 30 Jan 2001 11:14:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 5DFD84433E
	for <sip@lists.bell-labs.com>; Tue, 30 Jan 2001 11:13:54 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0UHDdj12772;
	Tue, 30 Jan 2001 11:13:39 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: Ben Campbell <bcampbell@dynamicsoft.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
Message-ID: <20010130111339.B11772@fdd.com>
References: <9BF66EBF6BEFD942915B4D4D45C051F309A8@DYN-TX-EXCH-001.dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F309A8@DYN-TX-EXCH-001.dynamicsoft.com>; from bcampbell@dynamicsoft.com on Mon, Jan 29, 2001 at 04:00:54PM -0500
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 30 Jan 2001 11:13:39 -0600


Amazon does sessions by a fake directory at the end of
URL's.  This technique has the advantage of never eliciting
a dialog box for any browser with any setting.  Please 
do not underestimate how unfamiliar* an end user can be.

If a UA is worried about destinations which badly handle
INVITEs with "handoff" headers.  That UA should deny 
HANDOFFs.  This will force the transferor to B2BUA, try
another strategy, or give up.  If the transferee already
pops up a message this is too late, and transferors
will B2BUA to begin with.  

We predict frequently the HANDOFF will be intercepted
by a B2BUA call controller and thus hidden from the 
transferee.  This is for privacy and reliability considerations,
and works most like the existing PSTN.

We confess, our goal is to build a transfer which works exactly
like the existing phone system, but happens to use SIP.  When
we complete this task, feel free to build a phone system
which works differently.  We hope you find some customers.

Yes, proxies should be able to administratively block
HANDOFF requests like any other.  Good point.  Do we need another 
sentence to cover this?  Are you proposing a special header or 
response code to indicate the proxy and not the end UA blocked it?
Does it make a difference to the HANDOFF sending UA?

We already have another method which is "prompt the remote human".
REFER to a web page does this best.  An audible
question does not need a SIP extension.  

Wouldn't the REFER request to a web page need two promptings?  
The first one is do you want to follow the URL and the second is the 
question on the web page.  I can do more damage
with a HTTP GET than a SIP INVITE, but most browsers follow 
302 redirects automatically anyway.

BTW, I am scared of what
a REFER with method=REFER prompt would look like to an end
user.  Clearly, the designers don't intend this.

Yes, sophisticated UA's with 19" monitors in expert mode will defy the 
draft and prompt the user.  It is their choice, and the IETF tries hard
not to mandate this behavior outside the protocol.  Hopefully the 
UA will prompt after the HANDOFF final response, but before the 
handoff-status, for timing reasons as you stated.

Thanks for the feedback.  

--
Rick
3Com

P.S.  I will be largely unreacable from Feb 1-6 due to
a vacation.  (Jackson Hole Wyoming :-)   

On Mon, Jan 29, 2001 at 04:00:54PM -0500, Ben Campbell wrote:
> Sorry for the lateness of my comments. I just came back from back to back
> vacation and flu.
> 
> I am concerned about the statement that a UA should automatically process a
> HANDOFF without asking the user. This seems dangerous to me; I envision a
> scenario where someone calls me, then transfers me to a billable service
> without my consent. 
> 
> I did notice the section about being able to administratively block such
> things at a proxy. I am still thinking about whether that is sufficient
> protection, as it would require some level of administrative forethought. I
> suspect we would find a lot of cases of closing the barn door after the
> horses have left.
> 
> I realize you added this requirement because of timing issues, but it seems
> to be a rather harsh presumption of decisions that at least sometimes should
> be left to the user.
> 
> > -----Original Message-----
> > From: Rick Dean [mailto:siplist@fdd.com]
> > Sent: Wednesday, January 17, 2001 12:27 PM
> > To: sip@lists.bell-labs.com
> > Subject: [SIP] draft-ietf-sip-handoff-00pre8.txt
> > 
> > 
> > 
> > Dear SIP list,
> > 
> > Although we would like more time to 
> > edit this poor draft, we feel a sneak
> > peek is warranted due to its urgent nature
> > with the upcomming meeting.
> > 
> > http://phonectl.sfour.com/draft-ietf-sip-handoff-00pre8.txt
> > 
> > Some significant differences from REFER are:
> >   * narrower scope
> >   * method completes without prompting
> >   * referred-by like header generated by transferee
> >   * location of headers for spawned invite
> >   * error processing & final notification
> > 
> > Cheers,
> > Rick
> > rick_dean@3com.com
> > 
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> > 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 30 14:04:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15629
	for <sip-archive@odin.ietf.org>; Tue, 30 Jan 2001 14:04:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C03924434A; Tue, 30 Jan 2001 13:05:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 6A08E44336
	for <sip@lists.bell-labs.com>; Tue, 30 Jan 2001 13:04:05 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA22040;
	Tue, 30 Jan 2001 14:06:41 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9K206C>; Tue, 30 Jan 2001 14:00:15 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F309AD@DYN-TX-EXCH-001.dynamicsoft.com>
From: Ben Campbell <bcampbell@dynamicsoft.com>
To: "'Rick Dean'" <siplist@fdd.com>
Cc: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
Subject: RE: [SIP] draft-ietf-sip-handoff-00pre8.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 30 Jan 2001 14:00:06 -0500

Hi Rick,

You appear to be arguing that the application you envision should not prompt
the user. I don't hold an opinion one way or another about that. Do you also
argue that _no_ implementation should ever prompt the user?

I was not suggesting that the draft should _mandate_ prompting the user,
only that it should not _prohibit_ it. It seems to me the developer or owner
of a UA is in a better position to decide if it makes sense to prompt the
user in a given implementation or situation than we are.



> -----Original Message-----
> From: Rick Dean [mailto:siplist@fdd.com]
> Sent: Tuesday, January 30, 2001 11:14 AM
> To: Ben Campbell
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
> 
> 
> 
> Amazon does sessions by a fake directory at the end of
> URL's.  This technique has the advantage of never eliciting
> a dialog box for any browser with any setting.  Please 
> do not underestimate how unfamiliar* an end user can be.
> 
> If a UA is worried about destinations which badly handle
> INVITEs with "handoff" headers.  That UA should deny 
> HANDOFFs.  This will force the transferor to B2BUA, try
> another strategy, or give up.  If the transferee already
> pops up a message this is too late, and transferors
> will B2BUA to begin with.  
> 
> We predict frequently the HANDOFF will be intercepted
> by a B2BUA call controller and thus hidden from the 
> transferee.  This is for privacy and reliability considerations,
> and works most like the existing PSTN.
> 
> We confess, our goal is to build a transfer which works exactly
> like the existing phone system, but happens to use SIP.  When
> we complete this task, feel free to build a phone system
> which works differently.  We hope you find some customers.
> 
> Yes, proxies should be able to administratively block
> HANDOFF requests like any other.  Good point.  Do we need another 
> sentence to cover this?  Are you proposing a special header or 
> response code to indicate the proxy and not the end UA blocked it?
> Does it make a difference to the HANDOFF sending UA?
> 
> We already have another method which is "prompt the remote human".
> REFER to a web page does this best.  An audible
> question does not need a SIP extension.  
> 
> Wouldn't the REFER request to a web page need two promptings?  
> The first one is do you want to follow the URL and the second is the 
> question on the web page.  I can do more damage
> with a HTTP GET than a SIP INVITE, but most browsers follow 
> 302 redirects automatically anyway.
> 
> BTW, I am scared of what
> a REFER with method=REFER prompt would look like to an end
> user.  Clearly, the designers don't intend this.
> 
> Yes, sophisticated UA's with 19" monitors in expert mode will 
> defy the 
> draft and prompt the user.  It is their choice, and the IETF 
> tries hard
> not to mandate this behavior outside the protocol.  Hopefully the 
> UA will prompt after the HANDOFF final response, but before the 
> handoff-status, for timing reasons as you stated.
> 
> Thanks for the feedback.  
> 
> --
> Rick
> 3Com
> 
> P.S.  I will be largely unreacable from Feb 1-6 due to
> a vacation.  (Jackson Hole Wyoming :-)   
> 
> On Mon, Jan 29, 2001 at 04:00:54PM -0500, Ben Campbell wrote:
> > Sorry for the lateness of my comments. I just came back 
> from back to back
> > vacation and flu.
> > 
> > I am concerned about the statement that a UA should 
> automatically process a
> > HANDOFF without asking the user. This seems dangerous to 
> me; I envision a
> > scenario where someone calls me, then transfers me to a 
> billable service
> > without my consent. 
> > 
> > I did notice the section about being able to 
> administratively block such
> > things at a proxy. I am still thinking about whether that 
> is sufficient
> > protection, as it would require some level of 
> administrative forethought. I
> > suspect we would find a lot of cases of closing the barn 
> door after the
> > horses have left.
> > 
> > I realize you added this requirement because of timing 
> issues, but it seems
> > to be a rather harsh presumption of decisions that at least 
> sometimes should
> > be left to the user.
> > 
> > > -----Original Message-----
> > > From: Rick Dean [mailto:siplist@fdd.com]
> > > Sent: Wednesday, January 17, 2001 12:27 PM
> > > To: sip@lists.bell-labs.com
> > > Subject: [SIP] draft-ietf-sip-handoff-00pre8.txt
> > > 
> > > 
> > > 
> > > Dear SIP list,
> > > 
> > > Although we would like more time to 
> > > edit this poor draft, we feel a sneak
> > > peek is warranted due to its urgent nature
> > > with the upcomming meeting.
> > > 
> > > http://phonectl.sfour.com/draft-ietf-sip-handoff-00pre8.txt
> > > 
> > > Some significant differences from REFER are:
> > >   * narrower scope
> > >   * method completes without prompting
> > >   * referred-by like header generated by transferee
> > >   * location of headers for spawned invite
> > >   * error processing & final notification
> > > 
> > > Cheers,
> > > Rick
> > > rick_dean@3com.com
> > > 
> > > 
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementer's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > "subscribe sip-implementors" in the body.
> > > 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 30 15:51:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17523
	for <sip-archive@odin.ietf.org>; Tue, 30 Jan 2001 15:51:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B28314434A; Tue, 30 Jan 2001 14:52:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id A2C4044336
	for <sip@lists.bell-labs.com>; Tue, 30 Jan 2001 14:51:29 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f0UKpI611246;
	Tue, 30 Jan 2001 14:51:18 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: Ben Campbell <bcampbell@dynamicsoft.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
Message-ID: <20010130145118.A27485@fdd.com>
References: <9BF66EBF6BEFD942915B4D4D45C051F309AD@DYN-TX-EXCH-001.dynamicsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F309AD@DYN-TX-EXCH-001.dynamicsoft.com>; from bcampbell@dynamicsoft.com on Tue, Jan 30, 2001 at 02:00:06PM -0500
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 30 Jan 2001 14:51:18 -0600


Agreed.  Sorry for coming on so strong.  I didn't mean to
be critical.  Thank you for posting your concerns.  
They are needed to design the best protocols.  
We do appreciate your feedback.  :-)

Yes, we hope all implementations never prompt their 
humans. This is not just for timing.  We acknowledge a 
security concern.  Hopefully, the explicit guidelines 
help make SIP easier to implement.  

The current drafts
statement reads "should" not "must".
Maybe additional explanation should be included.

Agreed, because of timing, human prompting 
should be done inbetween HANDOFF response and handoff-status.
Unfortunately, including this guideline 
will probably increase the number of UAs which will.
Let the implementors who build prompting 
UAs bear the burden of making it work....most
importantly so average* human users do not call
it broken.

--
Rick

On Tue, Jan 30, 2001 at 02:00:06PM -0500, Ben Campbell wrote:
> Hi Rick,
> 
> You appear to be arguing that the application you envision should not prompt
> the user. I don't hold an opinion one way or another about that. Do you also
> argue that _no_ implementation should ever prompt the user?
> 
> I was not suggesting that the draft should _mandate_ prompting the user,
> only that it should not _prohibit_ it. It seems to me the developer or owner
> of a UA is in a better position to decide if it makes sense to prompt the
> user in a given implementation or situation than we are.
> 
> 
> 
> > -----Original Message-----
> > From: Rick Dean [mailto:siplist@fdd.com]
> > Sent: Tuesday, January 30, 2001 11:14 AM
> > To: Ben Campbell
> > Cc: sip@lists.bell-labs.com
> > Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
> > 
> > 
> > 
> > Amazon does sessions by a fake directory at the end of
> > URL's.  This technique has the advantage of never eliciting
> > a dialog box for any browser with any setting.  Please 
> > do not underestimate how unfamiliar* an end user can be.
> > 
> > If a UA is worried about destinations which badly handle
> > INVITEs with "handoff" headers.  That UA should deny 
> > HANDOFFs.  This will force the transferor to B2BUA, try
> > another strategy, or give up.  If the transferee already
> > pops up a message this is too late, and transferors
> > will B2BUA to begin with.  
> > 
> > We predict frequently the HANDOFF will be intercepted
> > by a B2BUA call controller and thus hidden from the 
> > transferee.  This is for privacy and reliability considerations,
> > and works most like the existing PSTN.
> > 
> > We confess, our goal is to build a transfer which works exactly
> > like the existing phone system, but happens to use SIP.  When
> > we complete this task, feel free to build a phone system
> > which works differently.  We hope you find some customers.
> > 
> > Yes, proxies should be able to administratively block
> > HANDOFF requests like any other.  Good point.  Do we need another 
> > sentence to cover this?  Are you proposing a special header or 
> > response code to indicate the proxy and not the end UA blocked it?
> > Does it make a difference to the HANDOFF sending UA?
> > 
> > We already have another method which is "prompt the remote human".
> > REFER to a web page does this best.  An audible
> > question does not need a SIP extension.  
> > 
> > Wouldn't the REFER request to a web page need two promptings?  
> > The first one is do you want to follow the URL and the second is the 
> > question on the web page.  I can do more damage
> > with a HTTP GET than a SIP INVITE, but most browsers follow 
> > 302 redirects automatically anyway.
> > 
> > BTW, I am scared of what
> > a REFER with method=REFER prompt would look like to an end
> > user.  Clearly, the designers don't intend this.
> > 
> > Yes, sophisticated UA's with 19" monitors in expert mode will 
> > defy the 
> > draft and prompt the user.  It is their choice, and the IETF 
> > tries hard
> > not to mandate this behavior outside the protocol.  Hopefully the 
> > UA will prompt after the HANDOFF final response, but before the 
> > handoff-status, for timing reasons as you stated.
> > 
> > Thanks for the feedback.  
> > 
> > --
> > Rick
> > 3Com
> > 
> > P.S.  I will be largely unreacable from Feb 1-6 due to
> > a vacation.  (Jackson Hole Wyoming :-)   
> > 
> > On Mon, Jan 29, 2001 at 04:00:54PM -0500, Ben Campbell wrote:
> > > Sorry for the lateness of my comments. I just came back 
> > from back to back
> > > vacation and flu.
> > > 
> > > I am concerned about the statement that a UA should 
> > automatically process a
> > > HANDOFF without asking the user. This seems dangerous to 
> > me; I envision a
> > > scenario where someone calls me, then transfers me to a 
> > billable service
> > > without my consent. 
> > > 
> > > I did notice the section about being able to 
> > administratively block such
> > > things at a proxy. I am still thinking about whether that 
> > is sufficient
> > > protection, as it would require some level of 
> > administrative forethought. I
> > > suspect we would find a lot of cases of closing the barn 
> > door after the
> > > horses have left.
> > > 
> > > I realize you added this requirement because of timing 
> > issues, but it seems
> > > to be a rather harsh presumption of decisions that at least 
> > sometimes should
> > > be left to the user.
> > > 
> > > > -----Original Message-----
> > > > From: Rick Dean [mailto:siplist@fdd.com]
> > > > Sent: Wednesday, January 17, 2001 12:27 PM
> > > > To: sip@lists.bell-labs.com
> > > > Subject: [SIP] draft-ietf-sip-handoff-00pre8.txt
> > > > 
> > > > 
> > > > 
> > > > Dear SIP list,
> > > > 
> > > > Although we would like more time to 
> > > > edit this poor draft, we feel a sneak
> > > > peek is warranted due to its urgent nature
> > > > with the upcomming meeting.
> > > > 
> > > > http://phonectl.sfour.com/draft-ietf-sip-handoff-00pre8.txt
> > > > 
> > > > Some significant differences from REFER are:
> > > >   * narrower scope
> > > >   * method completes without prompting
> > > >   * referred-by like header generated by transferee
> > > >   * location of headers for spawned invite
> > > >   * error processing & final notification
> > > > 
> > > > Cheers,
> > > > Rick
> > > > rick_dean@3com.com
> > > > 
> > > > 
> > > > _______________________________________________
> > > > This list is for continuing development of the SIP protocol.
> > > > The sip-implementer's list is the place to discuss implementation,
> > > > and to receive advice on understanding existing sip.
> > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > > "subscribe sip-implementors" in the body.
> > > > 
> > 
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> > 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 30 17:32:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18575
	for <sip-archive@odin.ietf.org>; Tue, 30 Jan 2001 17:32:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5594C4434A; Tue, 30 Jan 2001 16:33:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 2AF5044336
	for <sip@lists.bell-labs.com>; Tue, 30 Jan 2001 11:50:31 -0500 (EST)
Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA29793
	for <sip@lists.bell-labs.com>; Tue, 30 Jan 2001 09:50:30 -0800 (PST)
Received: from mailman.cisco.com (localhost [127.0.0.1])
	by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f0UHoGl14235
	for <sip@lists.bell-labs.com>; Tue, 30 Jan 2001 09:50:16 -0800 (PST)
Received: from chsharp-w2k.cisco.com (rtp-vpn-107.cisco.com [10.82.192.107]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id JAA05934 for <sip@lists.bell-labs.com>; Tue, 30 Jan 2001 09:50:14 -0800 (PST)
Message-Id: <4.3.2.7.2.20010130124518.01b996c0@dogwood.cisco.com>
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: sip@lists.bell-labs.com
From: Chip Sharp <chsharp@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: [SIP] Question on "base" in draft-ietf-sip-isup-mime-07.txt
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 30 Jan 2001 12:49:56 -0500

Currently, the IANA considerations section of 
draft-ietf-sip-isup-mime-07.txt describes how to define new "version" 
fields, but does not describe how to define new "base" fields.

Given that new base protocols may be identified, shouldn't there be a 
description on how IANA assigns new "base" values?

Chip

-------------------------------------------------------------------
Chip Sharp                       Consulting Engineering
Cisco Systems
-------------------------------------------------------------------


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 30 18:38:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19253
	for <sip-archive@odin.ietf.org>; Tue, 30 Jan 2001 18:38:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3D4AD4433E; Tue, 30 Jan 2001 17:39:07 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97])
	by lists.bell-labs.com (Postfix) with ESMTP id 4453E44336
	for <sip@lists.bell-labs.com>; Tue, 30 Jan 2001 17:38:14 -0500 (EST)
Received: from dingdong.cisco.com (dingdong.cisco.com [64.102.17.16])
	by rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA03169;
	Tue, 30 Jan 2001 18:37:36 -0500 (EST)
Received: from cisco.com (klingle-ultra.cisco.com [64.102.93.47])
	by dingdong.cisco.com (Mirapoint)
	with ESMTP id AAT40661 (AUTH klingle);
	Tue, 30 Jan 2001 18:37:59 -0500 (EST)
Message-ID: <3A775049.433D0870@cisco.com>
From: Kevin Lingle <klingle@cisco.com>
X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jean-Francois Mule <jfmule@clarent.com>
Cc: sip-mib@egroups.com, drwalker@ss8networks.com,
        "'Joon Maeng'" <joon_maeng@vtel.com>, sip@lists.bell-labs.com
References: <005601c085d5$3e6887a0$0100007f@rwcjfmule01>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: [SIP] Re: [sip mib] work on SIP UA config timers and retries - action item #10
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 30 Jan 2001 18:37:45 -0500
Content-Transfer-Encoding: 7bit

jean-francios,

do we even need per method timer and retry config or should we just have
objects for T1 and T2 that are applicable to the entire system?  same
could be the case for the retry config - one retry count for the system.

the previous set of timer/retry config objects where an artifact of
a particular sip gateway implementation and did not correctly reflect
the concept of t1/t2 at all.  we expected them to be called into question.
(actually, they really haven't so far, but i expect they ultimate correctness 
 is not likely the reason for that ;)

i wanted to see the timers reworked in terms of t1/t2 to match up with 
the rfc, but i'm not sure we need to keep the per method approach.
we've had several new methods and your proposal is to add representation
for them.  i'm afraid that, while i wouldn't expect lots of new methods,
down the road there may still be more methods defined.  are we going to 
continue to update the MIB??  i hope not.  if we do things on a per method 
basis, we should try and minimize updates down the road.  in rev01 of 
sip-common-mib, we tried to address this issue where we had per method
statistics in sipMethodStatsTable.  we like the idea of the the method
being explicit in the object descriptor - at least for the known set of
core methods.  to handle future methods, we devised an additional table
(sipStatsExtMethodTable).  this table allowed for future expansion with
stats objects with the same semantics as those found in sipStatsMethodTable.
i can't say i relish the approach, but it's better than having to actually
publish an updated version of the mib down the road.

if we are to continue with per method timer/retry config, i think a similar 
mechanism for "extensions" (ie, new methods) would need to be added
as well.  since i don't really like the "extensions table" model all
that much, i'm asking whether we should even continue to consider per method
timer/retry configuration objects.

kevin

Jean-Francois Mule wrote:
> 

> There are 2 related tables in SIP-UA mib:  sipUACfgTimer and sipUACfgRetry.
> Based on the description of the variables, I'd like to propose the following
> additions and changes:
>         a/ Addition of timers + retry for OPTIONS method in SIP UA only (this is
> not in draft-01, but I see no particular reason for not adding it)
>         b/ Addition of timers + retry for INFO method (since stats do include INFO
> and INFO is an rfc...)
>         c/ Naming changes
> We should try to keep the same NAMING CONVENTIONS among the objects in those
> 2 tables. The timer naming rule is:
>         timer and retry counters should be named after the associated SIP method
> used (invite, ack, bye, ... - see below for example of this).  This renaming
> goes along well with the current description fields.
>         d/ Addition of default values according to RFC2543 using DEFVAL clause:  I
> took 500 ms by default and a total of 6 retries for the SIP INVITE as
> specified in section 10.5 of 2543.
>         e/ rework the description to mention T1/T2 timers...
> As for T1/T2 timers, I think the timers we can specify in the Timer table
> are the initial T1 timers (kind of a T1 timer for each method).  There is
> *no* specified T2 timer in the current table so I added one object under the
> name of sipUACfgTimerT2;  feel free to comment on the name/description.
> Took 4s as default T2 timer as per 2543.
> 
> Applying all these comments, this is what changes:
> 0/
>         add sipUACfgTimerOptions
>         add sipUACfgRetryOptions
>         add sipUACfgTimerInfo
>         add sipUACfgRetryInfo
>         add DEFVAL values
>         add sipUACfgTimerT2
>         misc: fixed end of description field in sipUACfgTimerRegister
>       misc: sipUACfgTimerReRegister had been already renamed into
> sipUACfgTimerRegister by Kevin Lingle
> 1/
>         rename sipUACfgTimerTrying into sipUACfgTimerInvite
>         keep sipUACfgRetryInvite
> 2/
>         rename sipUACfgTimerDisconnect into sipUACfgTimerBye
>         keep  sipUACfgRetryBye
> 3/
>       for sipUACfgRetryResponse, it seems that the description should
> specify "final" response (UA does not expect an ACK after a non-final
> response).  Added the term "final"  accordingly.
> -------------------------------------------------------
> -- Here is the ASN.1 with all the changes:
> -- syntax to be checked via mib compiler
> -------------------------------------------------------
>    --
>    -- SIP Timer Configuration
>    --
>    sipUACfgTimerTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF SipUACfgTimerEntry
>        MAX-ACCESS not-accessible
>        STATUS     current
>        DESCRIPTION
>             "This table contains timer configuration objects applicable
>              to each SIP user agent in this system.  The instances of
>              SIP entities are uniquely identified by applIndex."
>        ::= { sipUACfgTimer 1 }
> 
>    sipUACfgTimerEntry OBJECT-TYPE
>        SYNTAX     SipUACfgTimerEntry
>        MAX-ACCESS not-accessible
>        STATUS     current
>        DESCRIPTION
>             "A row of timer configuration."
>        INDEX { applIndex }
>        ::= { sipUACfgTimerTable 1 }
> 
>    SipUACfgTimerEntry ::=
>        SEQUENCE {
>                 sipUACfgTimerInvite        Integer32,
>                 sipUACfgTimerProv          Integer32,
>                 sipUACfgTimerAck           Integer32,
>                 sipUACfgTimerBye           Integer32,
>                 sipUACfgTimerRegister      Integer32,
>                 sipUACfgTimerOptions       Integer32,
>                 sipUACfgTimerInfo          Integer32,
>                 sipUACfgTimerT2            Integer32
>        }
> 
>    sipUACfgTimerInvite OBJECT-TYPE
>        SYNTAX      Integer32 (100..1000)
>        UNITS       "milliseconds"
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>             "This object specifies the time a user agent will wait to
>              receive a provisional response to an INVITE before
>              resending the INVITE."
>        DEFVAL { 500 }
>        ::= { sipUACfgTimerEntry 1 }
> 
>    sipUACfgTimerProv OBJECT-TYPE
>        SYNTAX      Integer32 (60000..300000)
>        UNITS       "milliseconds"
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>             "This object specifies the time a user agent will wait to
>              receive a final response to an INVITE before canceling the
>              transaction."
>        DEFVAL { 500 }
>    ::= { sipUACfgTimerEntry 2 }
> 
>    sipUACfgTimerAck OBJECT-TYPE
>        SYNTAX      Integer32 (100..1000)
>        UNITS       "milliseconds"
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>             "This object specifies the time a user agent will wait to
>              receive an ACK confirmation indicating that a session is
>              established."
>        DEFVAL { 500 }
>        ::= { sipUACfgTimerEntry 3 }
> 
>    sipUACfgTimerBye OBJECT-TYPE
>        SYNTAX      Integer32 (100..1000)
>        UNITS       "milliseconds"
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>             "This object specifies the time a user agent will wait to
>              receive a BYE confirmation indicating that a session is
>              terminated."
>        DEFVAL { 500 }
>        ::= { sipUACfgTimerEntry 4 }
> 
>    sipUACfgTimerRegister OBJECT-TYPE
>        SYNTAX      Integer32 (100..1000)
>        UNITS       "milliseconds"
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>             "This object specifies the time a user agent will wait
>              for a response to its REGISTER request before resending."
>        DEFVAL { 500 }
>        ::= { sipUACfgTimerEntry 5 }
> 
>    sipUACfgTimerOptions  OBJECT-TYPE
>        SYNTAX      Integer32 (100..1000)
>        UNITS       "milliseconds"
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>             "This object specifies the time a user agent will wait
>              for a response to its OPTIONS request before resending."
>        DEFVAL { 500 }
>        ::= { sipUACfgTimerEntry 6 }
> 
>    sipUACfgTimerInfo  OBJECT-TYPE
>        SYNTAX      Integer32 (100..1000)
>        UNITS       "milliseconds"
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>             "This object specifies the time a user agent will wait
>              for a response to its INFO request before resending."
>        DEFVAL { 500 }
>        ::= { sipUACfgTimerEntry 7 }
> 
>    sipUACfgTimerT2  OBJECT-TYPE
>        SYNTAX      Integer32 (200..10000)
>        UNITS       "milliseconds"
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>             "This object specifies the T2 timer for a user agent."
>        REFERENCE "Section 10.4 and 10.5 RFC2543"
>        DEFVAL { 4000 }
>        ::= { sipUACfgTimerEntry 8 }
> 
>    --
>    -- SIP Retry Configuration
>    --
>    sipUACfgRetryTable OBJECT-TYPE
>        SYNTAX      SEQUENCE OF SipUACfgRetryEntry
>        MAX-ACCESS not-accessible
>        STATUS     current
>        DESCRIPTION
>             "This table contains retry configuration objects applicable
>              to each SIP user agent in this system.  The instances of
>              SIP entities are uniquely identified by applIndex."
>        ::= { sipUACfgRetry 1 }
> 
>    sipUACfgRetryEntry OBJECT-TYPE
>        SYNTAX     SipUACfgRetryEntry
>        MAX-ACCESS not-accessible
>        STATUS     current
>        DESCRIPTION
>             "A row of retry configuration."
>        INDEX { applIndex }
>        ::= { sipUACfgRetryTable 1 }
> 
>    SipUACfgRetryEntry ::=
>        SEQUENCE {
>                 sipUACfgRetryInvite       Integer32,
>                 sipUACfgRetryBye          Integer32,
>                 sipUACfgRetryCancel       Integer32,
>                 sipUACfgRetryRegister     Integer32,
>                 sipUACfgRetryResponse     Integer32,
>                 sipUACfgRetryOptions      Integer32,
>                 sipUACfgRetryInfo         Integer32
>        }
> 
>    sipUACfgRetryInvite OBJECT-TYPE
>        SYNTAX      Integer32 (1..10)
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>             "This object will specify the number of times a user agent
>              will retry sending an INVITE request."
>        REFERENCE "Section 10.5 RFC 2543"
>            DEFVAL { 6 }
>        ::= { sipUACfgRetryEntry 1 }
> 
>    sipUACfgRetryBye OBJECT-TYPE
>        SYNTAX      Integer32 (1..10)
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>             "This object will specify the number of times a user agent
>              will retry sending a BYE request."
>        REFERENCE "Section 10.4 RFC 2543"
>        ::= { sipUACfgRetryEntry 2 }
> 
>    sipUACfgRetryCancel OBJECT-TYPE
>        SYNTAX      Integer32 (1..10)
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>             "This object will specify the number of times a user agent
>              will retry sending a CANCEL request."
>        REFERENCE "Section 10.4 RFC 2543"
>        ::= { sipUACfgRetryEntry 3 }
> 
>    sipUACfgRetryRegister OBJECT-TYPE
>        SYNTAX      Integer32 (1..10)
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>             "This object will specify the number of times a user agent
>              will retry sending a REGISTER request."
>        REFERENCE "Section 10.4 RFC 2543"
>        ::= { sipUACfgRetryEntry 4 }
> 
>    sipUACfgRetryResponse OBJECT-TYPE
>        SYNTAX      Integer32 (1..10)
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>             "This object will specify the number of times a user agent
>              will retry sending a final response and expecting an ACK."
>        ::= { sipUACfgRetryEntry 5 }
> 
>    sipUACfgRetryOptions OBJECT-TYPE
>        SYNTAX      Integer32 (1..10)
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>             "This object will specify the number of times a user agent
>              will retry sending an OPTIONS request."
>        REFERENCE "Section 10.4 RFC2543"
>        ::= { sipUACfgRetryEntry 6 }
> 
>    sipUACfgRetryInfo OBJECT-TYPE
>        SYNTAX      Integer32 (1..10)
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>             "This object will specify the number of times a user agent
>              will retry sending an INFO request."
>        REFERENCE "Section 2.4 RFC 2976"
>        ::= { sipUACfgRetryEntry 7 }
> 
>   ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                            Name: SIP-UA-MIB timers.my
>    SIP-UA-MIB timers.my    Type: unspecified type (application/octet-stream)
>                        Encoding: 7bit

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Kevin R. Lingle       919.392.2029
 checkout: http://wwwin-eng.cisco.com/Eng/IOS/SNMP_WWW/mib-police.html
 Sometimes I think I understand everything, then I regain consciousness.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 30 19:27:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19650
	for <sip-archive@odin.ietf.org>; Tue, 30 Jan 2001 19:27:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 562204433E; Tue, 30 Jan 2001 18:28:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail15b.boca15-verio.com (unknown [208.55.91.59])
	by lists.bell-labs.com (Postfix) with SMTP id E3A8544336
	for <sip@lists.bell-labs.com>; Tue, 30 Jan 2001 18:27:18 -0500 (EST)
Received: from 128.241.144.247 (128.241.144.247)
	by mail15b.boca15-verio.com (RS ver 1.0.58s) with SMTP id 020453181
	for <sip@lists.bell-labs.com>; Tue, 30 Jan 2001 19:26:31 -0500 (EST)
From: "Eric Burger" <eburger@snowshore.com>
To: <sip@lists.bell-labs.com>
Subject: RE: [SIP] Re: [Fwd: Announcements in SIP]
Message-ID: <NEBBLACLCLHMJBCAJGOEAEPACJAA.eburger@snowshore.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <B65B4F8437968F488A01A940B21982BF9AB21F@DYN-EXCH-001.dynamicsoft.com>
X-Loop-Detect: 1
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 30 Jan 2001 19:27:15 -0500
Content-Transfer-Encoding: 7bit

In my mind, text display and error-info would work just fine.  I do take
exception to early media, however.  We have the opportunity to plug the
early media hole.  Not only that, but we get to provide a more useful
system, as well!

Just because we can do early media doesn't mean we should.  Rather than
telling implementers that the far end can play a SIT announcement, we should
be suggesting an informative text message with an optional place to get an
audio version.

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg
> Sent: Monday, January 29, 2001 2:56 AM
> To: 'Henning G. Schulzrinne'; Bryan Byerly; sip@lists.bell-labs.com
> Subject: RE: [SIP] Re: [Fwd: Announcements in SIP]
>
>
> I've somehow only gotten a subset of the messages in this thread, so I'm a
> bit confused as to what exactly has been proposed.
>
> SIP has a way to handle in-band announcements, both before and
> after a call
> is setup. SIP also has a way to redirect a caller to fetch error
> information
> from a URL. All of this is in bis-02.
>
> Bryan has asked for, in addition to this:
>
> > Desired behavior 1: There should be a mechanism so that local
> > annoucements override network annoucements.
>
> I recall somewhere in this thread that there were proposals for
> things like
> SUpported: announcements, or something like that, which indicated whether
> the UA wanted to play local announcements or not. I think thats an awful
> idea. Ultimately, the issue comes down to control. If control resides with
> proxies in the network, the call will be answered and/or early media is
> used, and that is what the UA hears. If the call is redirected or
> responded
> to with an Error-Info back to the caller, then control resides in the UA,
> and it can play a local announcement. We already have a general purpose
> mechanism that allows a UA to request to remain in control - caller
> preferences. The request-disposition header can ask for proxy or redirect
> for this call:
>
> Request-Disposition: redirect
>
> this would have the effect of allowing the UA to control the local
> announcements. I'd rather use a general purpose mechanism like this than
> invent some one specifically for announcements.
>
> Bryan has also asked for:
> > > Desired behavior 2: There should be a mechanism so that
> > announcements
> > > are not billable.
>
> This has nothing to do with the protocol. A service provider bills for
> services. If they answer a call and play some kind of error announcement,
> its that providers responsibility to bill or not bill accordingly. I don't
> see what more needs be done in SIP for this.
>
> -Jonathan R.
>
>
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
>
> > -----Original Message-----
> > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> > Sent: Sunday, January 28, 2001 1:15 PM
> > To: Bryan Byerly; sip@lists.bell-labs.com
> > Subject: [SIP] Re: [Fwd: Announcements in SIP]
> >
> >
> > Bryan Byerly wrote:
> > >
> > > I'd appreciate your thoughts on annoucements.
> >
> > I probably missed most of the discussion on this, but almost all SIP
> > clients have a textual display of at least two lines, so they
> > can render
> > the 404 announcement as text. Thus, the lack of local announcements is
> > only a problem for gatewayed black phones (which doesn't make the
> > problem disappear, but qualifies the statement "no local announcement
> > capability").
> >
> > Also, this is very similar to early media and can be handled by the
> > proxy instructing an RTSP server, for example, to send audio to the IP
> > address contained in the caller SDP. Override would presumably be
> > handled similar for all early media, if text-to-speech conversion is
> > used.
> >
> > Finally, in case this hasn't been mentioned, 2543bis02 provides the
> > Error-Info header, which seems ideally suited to provide a
> > reference to
> > further information, using either an RTSP, SIP or HTTP URL (or even a
> > data URL, if you don't mind longer messages). The header allows a
> > comma-separated list, so that the callee can provide a range
> > of options
> > for the caller to choose from, depending on client capabilities and
> > human preferences. It does not seem unreasonable for a
> > gateway to speak
> > HTTP and RTSP, for example, to retrieve such announcements. (SIP
> > soft/hard UAs such as PC software or SIP phones, as I said above, are
> > not likely to face this problem.)
> >
> > Thus, I'm not exactly sure why this requires additional SIP mechanisms
> > or considerations.
> >
> >
> > > For this thread of discussion, we're talking about
> > announcements which
> > > are played when an error occurred during call setup.  For
> > instance, on
> > > 404, a message could be played "The URL you have dialed
> > B...O...B. is
> > > not in service, please check the URL or dial the operator for
> > > assistance".
> > >
> > > There are at least two desired behaviors w/r/t annoucements:
> > > Desired behavior 1: There should be a mechanism so that local
> > > annoucements override network annoucements.
> > > Desired behavior 2: There should be a mechanism so that
> > announcements
> > > are not billable.
> > >
> > > Like call forwarding features in SIP, there are implementable
> > > solutions to play annoucements using user agents or proxies.
> > >
> > > In the diagrams below, A, B, and C are user agents, Po is an
> > > originating proxy and Pt is a terminating proxy.
> > >
> > > User agent: Event based local announcement
> > > A                 Po             Pt
> > > |                  |              |
> > > |--INV Bob@B------>|              |
> > > |                  |              |
> > > |<-404-------------|              |
> > > |                  |              |
> > > A generates
> > > local audio
> > > indicating
> > > "The URL you have dialed B...O...B is not in service,
> > please check the
> > >
> > >  URL or dial the operator for assistance."
> > >
> > >
> > > Proxy: Event based call diversion (recursive)
> > > A                  Po             Pt        Announcement
> > >                                               Server
> > > |                  |              |             |
> > > |--INV Bob@B------>|              |             |
> > > |                  |--INV Bob@B-->|             |
> > > |                  |<-404---------|             |
> > > |            proxy implements     |             |
> > > |            call forward on 404  |             |
> > > |                  |--INV AnnServer------------>|
> > > |                  |  Diversion: Bob@B          |
> > > |                  |              |             |
> > > |<-200------------------------------------------|
> > > |<==="The URL you have dialed B...O...B is not==|
> > > |     in service, please check the URL or dial  |
> > > |     the operator for assistance"
> > >
> > >
> > > Both approaches are viable and there are advantages/disadvantages to
> > > each.  If all user agents supported local generation of
> > announcements,
> > > then an event based call diversion solution may not be needed.
> > > However, in today's world, many user agent implementations
> > do not have
> > > support for generating local announcements.
> > >
> > > Advantages for "event based local announcements"
> > > a) requires no network bandwidth
> > > b) requires no annoucements server
> > >
> > > Disadvantages for "event based local announcements"
> > > a) Not all SIP user agents support locally generated announcements
> > > b) provisioning issues for large-scale deployments. (i.e. If
> > > desirable, how would a network admin configure multi-vendor
> > SIP phones
> > > in his net with certain announcements).
> > >
> > > Advantages for "event based call diversion"
> > > a) Provides annoucement support in multi-vendor networks across all
> > > SIP user agents
> > > b) Provisioning is centralized at proxy and announcement server
> > >
> > > Disadvantages for "event based call diversion"
> > > a) requires network bandwidth to play annoucements
> > > b) requires presence of an announcements server
> > >
> > > I'm not interested in a holy war of which to use.  Each
> > solution will
> > > be appropriate for certain network deployments.  There will soon be
> > > implementations of event based local annoucements and event
> > based call
> > > diversion.  The more important issue is to define a mechanism to get
> > > desired feature interaction.
> > >
> > >
> > >
> > > Desired behavior 1: There should be a mechanism so that local
> > > annoucements override network annoucements.
> > >
> > > I would like the behavior that locally generated annoucements take
> > > precendence over proxy event based call diversion.  In other words,
> > > given a UA that is configured to play announcement X and
> > proxy that is
> > > configured to divert to an announcement server to play message Y, I
> > > want X to be played.  i.e. I want the behavior of a smart UA to be
> > > able to override the behavior (provided by proxies in the
> > network) to
> > > dumb UAs.
> > >
> > > Unfortunately, Po gets a chance to divert the call first:
> > > Proxy: Event based call diversion (recursive)
> > > A                  Po             Pt         AnnServer
> > > |                  |              |             |
> > > |--INV Bob@B------>|              |             |
> > > |                  |--INV Bob@B-->|             |
> > > |                  |<-404---------|             |
> > > |            proxy implements     |             |
> > > |            call forward on 404  |             |
> > > |                  |--INV AnnServer------------>|
> > > |                  |  Diversion: Bob@B          |
> > > |                  |              |             |
> > > |<-200------------------------------------------|
> > > |<==="The URL you have dialed B...O...B is not==|
> > > |     in service, please check the URL or dial  |
> > > |     the operator for assistance"
> > >
> > > Solution 1a: Non-recursive implementation of call diversion
> > > A possible solution would be to implement the diversion
> > > non-recursively:
> > > Proxy: Event based call diversion (non-recursive)
> > > A                  Po             Pt         AnnServer
> > > |                  |              |             |
> > > |--INV Bob@B------>|              |             |
> > > |                  |--INV Bob@B-->|             |
> > > |                  |<-404---------|             |
> > > |            proxy implements     |             |
> > > |            non-recursive        |             |
> > > |            call forward on 404  |             |
> > > |<-302-------------|              |             |
> > > |  Contact: AnnServer             |             |
> > > |  Diversion: Bob@B; reason=404   |             |
> > > |                  |              |             |
> > > |--INV AnnServer------------------------------->|
> > > |  Diversion: Bob@B; reason=404   |             |
> > > |                  |              |             |
> > > |<-200------------------------------------------|
> > > |<==="The URL you have dialed B...O...B is not==|
> > > |     in service, please check the URL or dial  |
> > > |     the operator for assistance"
> > >
> > > then the feature interaction could be:
> > > A ignores 302s with Diversion header indicating reason
> > codes for which
> > > A local generation of annoucements.
> > > Proxy: Event based call diversion (non-recursive)
> > > User agent: Event based local announcement (overriding 302s with
> > > already covered Diversion reason codes)
> > > A                  Po             Pt         AnnServer
> > > |                  |              |             |
> > > |--INV Bob@B------>|              |             |
> > > |                  |--INV Bob@B-->|             |
> > > |                  |<-404---------|             |
> > > |            proxy implements     |             |
> > > |            non-recursive        |             |
> > > |            call forward on 404  |             |
> > > |<-302-------------|              |             |
> > > |  Contact: AnnServer             |             |
> > > |  Diversion: Bob@B; reason=404   |             |
> > > |                  |              |             |
> > > A generates
> > > local audio
> > > indicating
> > > "The URL you have dialed B...O...B is not in service,
> > please check the
> > >
> > >  URL or dial the operator for assistance."
> > >
> > > Solution 1b: "Supported: annoucements" header
> > > Another possible solution would be for smart UAs (that support
> > > announcements) to use a "Supported: annoucements" header.  This
> > > supported header would be used to indicate to proxies that
> > they should
> > > not implement event based call forwarding (for annoucements):
> > >
> > > Proxy: Event based call diversion (deferring implementation to UAC
> > > when "Supported: annoucements" is present)
> > > User agent: Event based local announcement
> > > A                 Po             Pt
> > > |                  |              |
> > > |--INV Bob@B------>|              |
> > > |  Supported: annoucements        |
> > > |                  |              |
> > > |<-404-------------|              |
> > > |                  |              |
> > > A generates
> > > local audio
> > > indicating
> > > "The URL you have dialed B...O...B is not in service,
> > please check the
> > >
> > >  URL or dial the operator for assistance."
> > >
> > >
> > >
> > > Desired behavior 2:  There should be a mechanism so that
> > announcements
> > > are not billable.
> > >
> > > Another issue that has been raised w/r/t annoucements in networks
> > > where SIP signalling is billable.  The concern is that in
> > SIP networks
> > > where 200 is used to write a start record, implementation of proxy
> > > event based call diversion might generate a charge.
> > >
> > > Solution 2a: Play annoucements as early media
> > > One solution that has been proposed is to play annoucements as early
> > > media:
> > >
> > > For example, recursively:
> > > A                  Po             Pt         AnnServer
> > > |                  |              |             |
> > > |--INV Bob@B------>|              |             |
> > > |                  |--INV Bob@B-->|             |
> > > |                  |<-404---------|             |
> > > |            proxy implements     |             |
> > > |            call forward on 404  |             |
> > > |                  |--INV AnnServer------------>|
> > > |                  |  Diversion: Bob@B          |
> > > |                  |              |             |
> > > |<-183------------------------------------------|
> > > |  Content-Disposition: session                 |
> > > |<==="The URL you have dialed B...O...B is not==|
> > > |     in service, please check the URL or dial  |
> > > |     the operator for assistance"
> > > |<-CANCEL---------------------------------------|
> > > |--200 (CANCEL)-------------------------------->|
> > >
> > > or non-recursively:
> > > A                  Po             Pt         AnnServer
> > > |                  |              |             |
> > > |--INV Bob@B------>|              |             |
> > > |                  |--INV Bob@B-->|             |
> > > |                  |<-404---------|             |
> > > |            proxy implements     |             |
> > > |            non-recursive        |             |
> > > |            call forward on 404  |             |
> > > |<-302-------------|              |             |
> > > |  Contact: AnnServer             |             |
> > > |  Diversion: Bob@B; reason=404   |             |
> > > |                  |              |             |
> > > |--INV AnnServer------------------------------->|
> > > |  Diversion: Bob@B; reason=404   |             |
> > > |                  |              |             |
> > > |<-183------------------------------------------|
> > > |  Content-Disposition: session                 |
> > > |<==="The URL you have dialed B...O...B is not==|
> > > |     in service, please check the URL or dial  |
> > > |     the operator for assistance"
> > > |<-CANCEL---------------------------------------|
> > > |--200 (CANCEL)-------------------------------->|
> > >
> > > Solution 2b: Backend billing system is aware of (non-billable)
> > > Announcement Server URL
> > > Another possible solution is that the URL of the AnnServer could be
> > > well-known to the backend billing system and that any accounting
> > > records written connection to the AnnServer would not be billed.
> > >
> > > I'd like to solicit others' ideas, problems, and proposed solutions
> > > w/r/t annoucements in SIP.
> > >
> > > I'm also looking for co-authors to write an I-D w/r/t announcements.
> > > If interested, please contact me directly at byerly@cisco.com.
> > >
> > > thanks for your help,
> > > Bryan
> > >
> > > Bryan J. Byerly
> > > byerly@cisco.com
> > >
> > >
> >
> > --
> > Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> >
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
> >
>
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
>


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Tue Jan 30 23:31:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23472
	for <sip-archive@odin.ietf.org>; Tue, 30 Jan 2001 23:31:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 975F44433A; Tue, 30 Jan 2001 22:32:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by lists.bell-labs.com (Postfix) with ESMTP id EB60444336
	for <sip@lists.bell-labs.com>; Tue, 30 Jan 2001 22:31:17 -0500 (EST)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id VAA00336 for <sip@lists.bell-labs.com>; Tue, 30 Jan 2001 21:31:04 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id VAA27898 for <sip@lists.bell-labs.com>; Tue, 30 Jan 2001 21:27:07 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2651.58)
	id <DG4K87LJ>; Tue, 30 Jan 2001 22:31:03 -0600
Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8AE5@il27exm02.cig.mot.com>
From: Baniel Uri-CUB001 <Uri.Baniel@motorola.com>
To: Baniel Uri-CUB001 <Uri.Baniel@motorola.com>, sip@lists.bell-labs.com
Cc: Dyer William-QA1394 <Bill.Dyer@motorola.com>,
        Miller Trent-QA1400 <Trent.Miller@motorola.com>
Subject: RE: [SIP] Decoding the SIP URL
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="ISO-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Tue, 30 Jan 2001 22:30:58 -0600

So I guess my question is either just too dumb or too boring :(
Still, is there any good soul on the list, who has a moment to go over the
question and respond.

Thanks!

Uri

-----Original Message-----
From: Baniel Uri-CUB001 [mailto:Uri_Baniel-CUB001@email.mot.com]
Sent: Sunday, January 28, 2001 6:18 PM
To: sip@lists.bell-labs.com
Subject: [SIP] Decoding the SIP URL


Say a UAC gets the following SIP URL from its user in the 'To' and 'request
URI' fields: "t.watson@ieee.org".
How does the UAC 'guess' if 'ieee.org' refer to a specific host or a domain?
Looks like according Bis02 para 1.4.2, the UAC tries to get DNS SRV record
first, and then A record if the former query has failed. Is that true? If
yes, looks like according the DNS RFC, one may issue a DNS query w/ multiple
types (e.g. _sip, a, aaaa) and act based on the response.
Was that the intention of Bis?

============================================
Uri.Baniel@motorola.com, 
Tel: (847) 632 4616; Fax: (847) 632 3963; 
============================================


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 01:20:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25655
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 01:20:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 888BD4433A; Wed, 31 Jan 2001 00:21:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6])
	by lists.bell-labs.com (Postfix) with ESMTP id 6F8F044336
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 00:20:51 -0500 (EST)
Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23])
	by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id MAA26260
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 12:00:10 GMT
Received: from ecvwall1.wipro.com ([192.168.181.23])
          by ecmail.mail.wipro.com (Netscape Messaging Server 3.6)
           with SMTP id AAA67B5 for <sip@lists.bell-labs.com>;
          Wed, 31 Jan 2001 11:49:14 +0530
Received: from aravali.wipro.com ([192.168.205.55])
          by platinum.mail.wipro.com (Netscape Messaging Server 3.6)
           with SMTP id AAA5F52 for <sip@lists.bell-labs.com>;
          Wed, 31 Jan 2001 11:48:27 +0530
Message-ID: <008101c08b4f$9d2b1ee0$37cda8c0@wipro.com>
From: "Venkata Rajesh Velamakanni" <rajesh.venkata@wipro.com>
To: <sip@lists.bell-labs.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_007E_01C08B7D.B68646C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Subject: [SIP] Regarding Tag field in From header
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 12:02:41 +0530

This is a multi-part message in MIME format.

------=_NextPart_000_007E_01C08B7D.B68646C0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hello All,

I am new to this mailing list and have question about Tag field.
Could you please answer my query.

I would like to know the significance of the Tag field in the From=20
header field. How exactly this Tag field in the From header is being =
useful?


Thanks in Advance,
Rajesh.

------=_NextPart_000_007E_01C08B7D.B68646C0
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Times New Roman">Hello All,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman">I am new to this mailing list and =
have=20
question about Tag field.</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">Could you please&nbsp;</FONT><FONT=20
face=3D"Times New Roman">answer&nbsp;my query.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman">I would like to know the =
significance of the=20
<FONT color=3D#0000ff>Tag field in the From </FONT></FONT></DIV>
<DIV><FONT face=3D"Times New Roman">header field.&nbsp;How exactly this =
Tag field=20
in the From header is being useful?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman">Thanks in Advance,</FONT></DIV>
<DIV><FONT face=3D"Times New Roman">Rajesh.</FONT></DIV></BODY></HTML>

------=_NextPart_000_007E_01C08B7D.B68646C0--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 03:44:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08175
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 03:44:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id DE0074433A; Wed, 31 Jan 2001 02:45:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web9807.mail.yahoo.com (web9807.mail.yahoo.com [216.136.129.32])
	by lists.bell-labs.com (Postfix) with SMTP id 989B044336
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 02:44:43 -0500 (EST)
Message-ID: <20010131084430.46645.qmail@web9807.mail.yahoo.com>
Received: from [203.197.178.222] by web9807.mail.yahoo.com; Wed, 31 Jan 2001 00:44:30 PST
From: laks hmi <lakshmiam@yahoo.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] Regarding header in SIP-URL
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 00:44:30 -0800 (PST)

Hi All,

In SIP-URL, header = hname "=" hvalue.
Here hvalue can be zero or more, so in the
case of zero characters "=" character is not needed
So can i put header = hname [ "=" hvalue].


Regards
lakshmi


__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 04:25:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08395
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 04:25:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 902534433A; Wed, 31 Jan 2001 03:26:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92])
	by lists.bell-labs.com (Postfix) with SMTP id DDE6444336
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 03:25:31 -0500 (EST)
Received: from gecko.ubiquity.net by drago1.ubiquity.net
          via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 31 Jan 2001 09:25:18 UT
Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef)
	id JAA23863; Wed, 31 Jan 2001 09:23:22 GMT
Message-ID: <3A77D98A.894563A4@ubiquity.net>
From: Neil Deason <ndeason@ubiquity.net>
Organization: Ubiquity Software Corporation Limited
X-Mailer: Mozilla 4.51 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Venkata Rajesh Velamakanni <rajesh.venkata@wipro.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Regarding Tag field in From header
References: <008101c08b4f$9d2b1ee0$37cda8c0@wipro.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 09:23:22 +0000
Content-Transfer-Encoding: 7bit

> Venkata Rajesh Velamakanni wrote:
> 
> Hello All,
> 
> I am new to this mailing list and have question about Tag field.
> Could you please answer my query.

This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss
implementation,
and to receive advice on understanding existing sip.

To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body. 

Please post future questions like this there, but to answer
now anyway...

> I would like to know the significance of the Tag field in the From
> header field. How exactly this Tag field in the From header is being useful?

Tag params are a mechanism to distinguish multiple instances
of the same user identified by a single SIP URL. A tag in the
From MUST be added when it is possible that >1 instance of
a user sharing a SIP address can make inivtations with the
same Call-ID.

Cheers,
Neil.
-- 
Ubiquity Software Corporation, UK        http://www.ubiquity.net

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 05:22:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08768
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 05:22:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id A28F24433A; Wed, 31 Jan 2001 04:23:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web10304.mail.yahoo.com (web10304.mail.yahoo.com [216.136.130.82])
	by lists.bell-labs.com (Postfix) with SMTP id 5184F44336
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 04:22:53 -0500 (EST)
Message-ID: <20010131102239.52856.qmail@web10304.mail.yahoo.com>
Received: from [203.200.4.251] by web10304.mail.yahoo.com; Wed, 31 Jan 2001 02:22:39 PST
From: james jack <sipjames@yahoo.com>
To: sip-implementors@cs.columbia.edu
Cc: sip@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] the contact fields in REGISTER request
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 02:22:39 -0800 (PST)

Dear All:
   I have one question to consult, in REGISTER
request,
should the contact contain so many parameters as
listed
in SIP_URL.

SIP-URL = ”sip:” [ userinfo ”@” ] hostport
url-parameters [ headers ]
userinfo = [ user j telephone-subscriber ] [ ”:”
password ]
user = *( unreserved j escaped j user-unreserved )
user-unreserved = ”&” j ”=” j ”+” j ”$” j ”,” j ”;” j
”?” j ”/”
password = *( unreserved j escaped j
”&” j ”=” j ”+” j ”$” j ”,” )
hostport = host [ ”:” port ]
host = hostname j IPv4address j IPv6reference
hostname = *( domainlabel ”.” ) toplabel [ ”.” ]
domainlabel = alphanum
j alphanum *( alphanum j ”-” ) alphanum
toplabel = alpha j alpha *( alphanum j ”-” ) alphanum
IPv4address = 1*3DIGIT ”.” 1*3DIGIT ”.” 1*3DIGIT ”.”
1*3DIGIT
IPv6reference = ”[” IPv6address ”]”
IPv6address = hexpart [ ”:” IPv4address ]
hexpart = hexseq j hexseq ”::” [ hexseq ] j ”::” [
hexseq ]
hexseq = hex4 *( ”:” hex4)
hex4 = 1*4HEX
port = 1*DIGIT
url-parameters = *( ”;” url-parameter)
url-parameter = transport-param j user-param j
method-param
j ttl-param j maddr-param j other-param
transport-param = ”transport=”
( ”udp” j ”tcp” j ”sctp” j ”tls” j other-transport)
other-transport = token
user-param = ”user=” ( ”phone” j ”ip” j other-user)
other-user = token
method-param = ”method=” Method
ttl-param = ”ttl=” ttl
maddr-param = ”maddr=” host
other-param = pname [ ”=” pvalue ]
pname = 1*paramchar
pvalue = 1*paramchar
paramchar = param-unreserved j unreserved j escaped
param-unreserved = ”[” j ”]” j ”/” j ”:” j ”&” j ”+” j
”$”
headers = ”?” header *( ”&” header )
header = hname ”=” hvalue
hname = 1*( hnv-unreserved j unreserved j escaped )
hvalue = *( hnv-unreserved j unreserved j escaped )
hnv-unreserved = ”[” j ”]” j ”/” j ”?” j ”:” j ”+” j
”$”
  My meaning is that is it necessary to have so many 
parameters to be stored in realization?
   I think some parameter such as Method-parameter,ttl
ttl-param = ”ttl=” ttl, maddr-param = ”maddr=” host
etc, there is no need for them to appear in REGISTER 
request.
 This is my opinion.
 I am looking forwards to getting suggestion and idea
from every one!
  Best Regards!
                     Yours: James
  






__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 05:54:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08851
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 05:54:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3F3CD4433C; Wed, 31 Jan 2001 04:55:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31])
	by lists.bell-labs.com (Postfix) with ESMTP id 7AD7E4433A
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 04:54:46 -0500 (EST)
Received: from znsgd00t.europe.nortel.com by qnsgs000.nortel.com;
          Wed, 31 Jan 2001 10:51:02 +0000
Received: from nwcwi1a.europe.nortel.com ([47.30.176.175]) 
          by znsgd00t.europe.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id D0VTBAY0; Wed, 31 Jan 2001 10:51:00 -0000
Received: by nwcwi1a.europe.nortel.com with Internet Mail Service (5.5.2650.21) 
          id <DW98RAQ0>; Wed, 31 Jan 2001 10:50:54 -0000
Message-ID: <A3C2399B2FACD411A54200508BE39C7419AA4A@zwcwd00r.europe.nortel.com>
X-Sybari-Space: 00000000 00000000 00000000
From: "Joshua Moloney" <jmoloney@nortelnetworks.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08B73.7EDF09A0"
Subject: [SIP] Overlap call setup
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 10:49:33 -0000

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_01C08B73.7EDF09A0
Content-Type: text/plain

Greetings,

I would like to ask for clarification regarding the implementation of
Overlap.

I'll begin by referring to paragraph 3, section 6.1.2 of
"draft-ietf-isup-sip-00":

It is stated that INVITEs sent after the first one (containing extra digits
in the 'To' field) are to be treated as new Call-Legs, seeing as the
contents of their 'To' headers differ. As such, there is no relationship
between their CSeq values.

If this is the case, how is it possible to ensure correct digit ordering
over an 'unreliable' transport layer like UDP? It would seem logical that
the call originator _would_ use contiguous CSeq values, as it would be
'aware' of the fact that the INVITEs are for the same call.

I believe that this issue was raised on the SIP list on 19 November 1999 by
Gonzalo C and Jonathan R. The subject of the messages was "Re: Comments on
draft-camarillo-mmusic-sip-isup-bcp-00.txt". The outcome of the exchange
appeared to be an agreement that CSeq ordering should be employed.

However, does this in any way imply that under such circumstances the
INVITEs would/should belong to the same Call-Leg? After all, the concept of
Overlap does not seem to 'fit in' with the concept behind multiple Call-Legs
anyway.

If there has been a change in thinking behind the problem, and the latest
draft is correct, please could you explain how the ordering problem will be
overcome. If not, perhaps the draft needs modification to include these
considerations...


Regards,

Josh Moloney

------_=_NextPart_001_01C08B73.7EDF09A0
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.2652.35">
<TITLE>Overlap call setup</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Greetings,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I would like to ask for clarification =
regarding the implementation of Overlap.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I'll begin by referring to paragraph =
3, section 6.1.2 of &quot;draft-ietf-isup-sip-00&quot;:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">It is stated that INVITEs sent after =
the first one (containing extra digits in the 'To' field) are to be =
treated as new Call-Legs, seeing as the contents of their 'To' headers =
differ. As such, there is no relationship between their CSeq =
values.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If this is the case, how is it =
possible to ensure correct digit ordering over an 'unreliable' =
transport layer like UDP? It would seem logical that the call =
originator _would_ use contiguous CSeq values, as it would be 'aware' =
of the fact that the INVITEs are for the same call.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I believe that this issue was raised =
on the SIP list on 19 November 1999 by Gonzalo C and Jonathan R. The =
subject of the messages was &quot;Re: Comments on =
draft-camarillo-mmusic-sip-isup-bcp-00.txt&quot;. The outcome of the =
exchange appeared to be an agreement that CSeq ordering should be =
employed.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">However, does this in any way imply =
that under such circumstances the INVITEs would/should belong to the =
same Call-Leg? After all, the concept of Overlap does not seem to 'fit =
in' with the concept behind multiple Call-Legs anyway.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If there has been a change in thinking =
behind the problem, and the latest draft is correct, please could you =
explain how the ordering problem will be overcome. If not, perhaps the =
draft needs modification to include these considerations...</FONT></P>
<BR>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Josh Moloney</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08B73.7EDF09A0--

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 06:30:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09020
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 06:30:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 18F7E4433A; Wed, 31 Jan 2001 05:31:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from web10315.mail.yahoo.com (web10315.mail.yahoo.com [216.136.173.157])
	by lists.bell-labs.com (Postfix) with SMTP id 3432D44336
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 05:30:13 -0500 (EST)
Message-ID: <20010131112959.61785.qmail@web10315.mail.yahoo.com>
Received: from [203.200.4.251] by web10315.mail.yahoo.com; Wed, 31 Jan 2001 03:29:59 PST
From: james jack <sipjames@yahoo.com>
To: sip@lists.bell-labs.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [SIP] Consultation on CNonce
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 03:29:59 -0800 (PST)

Dear All:
   I have read RFC2617(HTTP authentication), where for
Digest Authorization,  the format is listed as the
following:
       credentials      = "Digest" digest-response
       digest-response  = 1#(username | realm | nonce
| digest-uri
                       | response | [algorithm] |
[cnonce] |
                       [opaque] | [message-qop] |
                       [nonce-count]  | [auth-param])

       username         = "username" "="
username-value
       username-value   = quoted-string
       digest-uri       = "uri" "=" digest-uri-value
       digest-uri-value = Request-Uri   
       message-qop      = "qop" "=" qop-value
       cnonce           = "cnonce" "=" cnonce-value
       cnonce-value     = nonce-value
       nonce-count      = "nc" "=" nc-value
       nc-value         = 8LHEX
       response         = "response" "="
request-digest
       request-digest = <"> 32LHEX <">
       LHEX             =  "0" | "1" | "2" | "3" |
                                  "4" | "5" | "6" |
"7" |
                                 "8" | "9" | "a" | "b"
|
                                 "c" | "d" | "e" | "f"


There is no narration on the generation of CNonce,
according to my understanding, will this CNonce will
be given by any random string?

 Could anyone give me some suggestion and idea?
 Best Regards!
                  Yours: James

__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 09:40:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15319
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 09:40:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 293994433A; Wed, 31 Jan 2001 08:41:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 8360944336
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 08:40:53 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA09225;
	Wed, 31 Jan 2001 09:40:38 -0500 (EST)
Message-ID: <3A7823E6.113A723B@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Eric Burger <eburger@snowshore.com>
Cc: sip@lists.bell-labs.com
Subject: Re: [SIP] Re: [Fwd: Announcements in SIP]
References: <NEBBLACLCLHMJBCAJGOEAEPACJAA.eburger@snowshore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 09:40:38 -0500
Content-Transfer-Encoding: 7bit

Eric Burger wrote:
> 
> In my mind, text display and error-info would work just fine.  I do take
> exception to early media, however.  We have the opportunity to plug the
> early media hole.  Not only that, but we get to provide a more useful
> system, as well!
> 
> Just because we can do early media doesn't mean we should.  Rather than
> telling implementers that the far end can play a SIT announcement, we should
> be suggesting an informative text message with an optional place to get an
> audio version.

Just in case my position was unclear: I fully agree. Early media is a
last-resort mechanism and should be avoided where possible, as it is far
less semantically rich than more explicit alternatives.


-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 09:57:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16274
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 09:57:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id EBA234433A; Wed, 31 Jan 2001 08:58:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id ADCAC44336
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 08:57:03 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA00582;
	Wed, 31 Jan 2001 09:59:41 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KJB60>; Wed, 31 Jan 2001 09:53:13 -0500
Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F309B1@DYN-TX-EXCH-001.dynamicsoft.com>
From: Ben Campbell <bcampbell@dynamicsoft.com>
To: "'Rick Dean'" <siplist@fdd.com>, Ben Campbell <bcampbell@dynamicsoft.com>
Cc: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
Subject: RE: [SIP] draft-ietf-sip-handoff-00pre8.txt
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 09:53:07 -0500

Hi Rick,

No apology required. I did not get any impression that you were being
critical or coming on too strong.

I think we have some dissagreement on the user interface philosopy side,
where you wish to build something that acts like a phone, and I wish phones
would act more like computers(i.e the few sophiticated users out there
should not be forced to work at the lowest common denominator). I do not
expect (or feel any need) to resolve that disagreement here; I think there
is room for both approaches.

My point was that the protocol should not favor one of those philosophies
over the other, but instead should allow both approaches where possible. A
timing issue is one thing, pushing for a particular user experience is
another. I would prefer to see the "should" language softened, except for
where it has a real protocol implication. Then you could discuss user
experience implications in a non-normative section.

Ben.

> -----Original Message-----
> From: Rick Dean [mailto:siplist@fdd.com]
> Sent: Tuesday, January 30, 2001 2:51 PM
> To: Ben Campbell
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
> 
> 
> 
> Agreed.  Sorry for coming on so strong.  I didn't mean to
> be critical.  Thank you for posting your concerns.  
> They are needed to design the best protocols.  
> We do appreciate your feedback.  :-)
> 
> Yes, we hope all implementations never prompt their 
> humans. This is not just for timing.  We acknowledge a 
> security concern.  Hopefully, the explicit guidelines 
> help make SIP easier to implement.  
> 
> The current drafts
> statement reads "should" not "must".
> Maybe additional explanation should be included.
> 
> Agreed, because of timing, human prompting 
> should be done inbetween HANDOFF response and handoff-status.
> Unfortunately, including this guideline 
> will probably increase the number of UAs which will.
> Let the implementors who build prompting 
> UAs bear the burden of making it work....most
> importantly so average* human users do not call
> it broken.
> 
> --
> Rick
> 
> On Tue, Jan 30, 2001 at 02:00:06PM -0500, Ben Campbell wrote:
> > Hi Rick,
> > 
> > You appear to be arguing that the application you envision 
> should not prompt
> > the user. I don't hold an opinion one way or another about 
> that. Do you also
> > argue that _no_ implementation should ever prompt the user?
> > 
> > I was not suggesting that the draft should _mandate_ 
> prompting the user,
> > only that it should not _prohibit_ it. It seems to me the 
> developer or owner
> > of a UA is in a better position to decide if it makes sense 
> to prompt the
> > user in a given implementation or situation than we are.
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Rick Dean [mailto:siplist@fdd.com]
> > > Sent: Tuesday, January 30, 2001 11:14 AM
> > > To: Ben Campbell
> > > Cc: sip@lists.bell-labs.com
> > > Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
> > > 
> > > 
> > > 
> > > Amazon does sessions by a fake directory at the end of
> > > URL's.  This technique has the advantage of never eliciting
> > > a dialog box for any browser with any setting.  Please 
> > > do not underestimate how unfamiliar* an end user can be.
> > > 
> > > If a UA is worried about destinations which badly handle
> > > INVITEs with "handoff" headers.  That UA should deny 
> > > HANDOFFs.  This will force the transferor to B2BUA, try
> > > another strategy, or give up.  If the transferee already
> > > pops up a message this is too late, and transferors
> > > will B2BUA to begin with.  
> > > 
> > > We predict frequently the HANDOFF will be intercepted
> > > by a B2BUA call controller and thus hidden from the 
> > > transferee.  This is for privacy and reliability considerations,
> > > and works most like the existing PSTN.
> > > 
> > > We confess, our goal is to build a transfer which works exactly
> > > like the existing phone system, but happens to use SIP.  When
> > > we complete this task, feel free to build a phone system
> > > which works differently.  We hope you find some customers.
> > > 
> > > Yes, proxies should be able to administratively block
> > > HANDOFF requests like any other.  Good point.  Do we need another 
> > > sentence to cover this?  Are you proposing a special header or 
> > > response code to indicate the proxy and not the end UA blocked it?
> > > Does it make a difference to the HANDOFF sending UA?
> > > 
> > > We already have another method which is "prompt the remote human".
> > > REFER to a web page does this best.  An audible
> > > question does not need a SIP extension.  
> > > 
> > > Wouldn't the REFER request to a web page need two promptings?  
> > > The first one is do you want to follow the URL and the 
> second is the 
> > > question on the web page.  I can do more damage
> > > with a HTTP GET than a SIP INVITE, but most browsers follow 
> > > 302 redirects automatically anyway.
> > > 
> > > BTW, I am scared of what
> > > a REFER with method=REFER prompt would look like to an end
> > > user.  Clearly, the designers don't intend this.
> > > 
> > > Yes, sophisticated UA's with 19" monitors in expert mode will 
> > > defy the 
> > > draft and prompt the user.  It is their choice, and the IETF 
> > > tries hard
> > > not to mandate this behavior outside the protocol.  Hopefully the 
> > > UA will prompt after the HANDOFF final response, but before the 
> > > handoff-status, for timing reasons as you stated.
> > > 
> > > Thanks for the feedback.  
> > > 
> > > --
> > > Rick
> > > 3Com
> > > 
> > > P.S.  I will be largely unreacable from Feb 1-6 due to
> > > a vacation.  (Jackson Hole Wyoming :-)   
> > > 
> > > On Mon, Jan 29, 2001 at 04:00:54PM -0500, Ben Campbell wrote:
> > > > Sorry for the lateness of my comments. I just came back 
> > > from back to back
> > > > vacation and flu.
> > > > 
> > > > I am concerned about the statement that a UA should 
> > > automatically process a
> > > > HANDOFF without asking the user. This seems dangerous to 
> > > me; I envision a
> > > > scenario where someone calls me, then transfers me to a 
> > > billable service
> > > > without my consent. 
> > > > 
> > > > I did notice the section about being able to 
> > > administratively block such
> > > > things at a proxy. I am still thinking about whether that 
> > > is sufficient
> > > > protection, as it would require some level of 
> > > administrative forethought. I
> > > > suspect we would find a lot of cases of closing the barn 
> > > door after the
> > > > horses have left.
> > > > 
> > > > I realize you added this requirement because of timing 
> > > issues, but it seems
> > > > to be a rather harsh presumption of decisions that at least 
> > > sometimes should
> > > > be left to the user.
> > > > 
> > > > > -----Original Message-----
> > > > > From: Rick Dean [mailto:siplist@fdd.com]
> > > > > Sent: Wednesday, January 17, 2001 12:27 PM
> > > > > To: sip@lists.bell-labs.com
> > > > > Subject: [SIP] draft-ietf-sip-handoff-00pre8.txt
> > > > > 
> > > > > 
> > > > > 
> > > > > Dear SIP list,
> > > > > 
> > > > > Although we would like more time to 
> > > > > edit this poor draft, we feel a sneak
> > > > > peek is warranted due to its urgent nature
> > > > > with the upcomming meeting.
> > > > > 
> > > > > http://phonectl.sfour.com/draft-ietf-sip-handoff-00pre8.txt
> > > > > 
> > > > > Some significant differences from REFER are:
> > > > >   * narrower scope
> > > > >   * method completes without prompting
> > > > >   * referred-by like header generated by transferee
> > > > >   * location of headers for spawned invite
> > > > >   * error processing & final notification
> > > > > 
> > > > > Cheers,
> > > > > Rick
> > > > > rick_dean@3com.com
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > This list is for continuing development of the SIP protocol.
> > > > > The sip-implementer's list is the place to discuss 
> implementation,
> > > > > and to receive advice on understanding existing sip.
> > > > > To subscribe to it, send mail to 
> majordomo@cs.columbia.edu with
> > > > > "subscribe sip-implementors" in the body.
> > > > > 
> > > 
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementer's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > "subscribe sip-implementors" in the body.
> > > 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 10:41:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17914
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 10:41:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5B8BC4433A; Wed, 31 Jan 2001 09:42:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from email5.etsi.org (email5.etsi.fr [212.234.161.50])
	by lists.bell-labs.com (Postfix) with ESMTP id D49B444336
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 09:41:08 -0500 (EST)
Received: by EMAIL5 with Internet Mail Service (5.5.2650.21)
	id <DWZMGQAA>; Wed, 31 Jan 2001 16:40:40 +0100
Message-ID: <337FC70FD51CD411A3500008C70D56F1500309@IS~EMAIL1>
From: Nathalie Guinet <Nathalie.Guinet@etsi.fr>
To: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] 2nd Reminder to SIP Bake-off Participants in France (26-30 March
 2001 )  -  Hotel room booking
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 16:40:44 +0100

Dear SIP Bake-off participants,

Please note that the Early Bird Room Rate of the Royal Hotel Casino in
Mandelieu (FR) is expiring
today. After that date, the rate will be increased. Should you want to
benefit from the preferential rates, you may use this form to make your
booking.
http://webapp.etsi.org/interop3/doc/registration.doc

Today's special gift : a few links to prepare your suitcase and your spare
time in France if you have time not "to bake-off"  :-))
http://weather.yahoo.com/forecast/Nice_FR_c.html
http://www.beyond.fr/ (FYI, we are in the department Provence Alpes Cote
d'Azur)

Feel free to send me an e-mail, should you have any worries with your
reservations.

Nathalie Guinet
ETSI Bake-off Service
Event Coordinator
Tel: +33 (0)4 92 94 43 62
Fax: + 33 (0)4 92 38 49 13

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 11:03:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18607
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 11:03:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 1FC304433A; Wed, 31 Jan 2001 10:04:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56])
	by lists.bell-labs.com (Postfix) with ESMTP id 309B044336
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 10:03:55 -0500 (EST)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Wed, 31 Jan 2001 10:30:33 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <D33PG679>; Wed, 31 Jan 2001 10:27:51 -0500
Message-ID: <28560036253BD41191A10000F8BCBD110389EE9E@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: Baniel Uri-CUB001 <Uri.Baniel@motorola.com>, sip@lists.bell-labs.com
Cc: Dyer William-QA1394 <Bill.Dyer@motorola.com>,
        Miller Trent-QA1400 <Trent.Miller@motorola.com>
Subject: RE: [SIP] Decoding the SIP URL
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08B9A.589A1010"
X-Orig: <taylor@americasm01.nt.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 10:27:39 -0500

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_01C08B9A.589A1010
Content-Type: text/plain;
	charset="ISO-8859-1"

I think you clearly reflect the intent of the relevant section (1.4.2) in
the bis document.  Note the reservation that you don't try for SRV if the
port in the Request-URI differs from 5060.

> -----Original Message-----
> From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com]
> Sent: Tuesday, January 30, 2001 11:31 PM
> To: Baniel Uri-CUB001; sip@lists.bell-labs.com
> Cc: Dyer William-QA1394; Miller Trent-QA1400
> Subject: RE: [SIP] Decoding the SIP URL
> 
> 
> So I guess my question is either just too dumb or too boring :(
> Still, is there any good soul on the list, who has a moment 
> to go over the
> question and respond.
> 
> Thanks!
> 
> Uri
> 
> -----Original Message-----
> From: Baniel Uri-CUB001 [mailto:Uri_Baniel-CUB001@email.mot.com]
> Sent: Sunday, January 28, 2001 6:18 PM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Decoding the SIP URL
> 
> 
> Say a UAC gets the following SIP URL from its user in the 
> 'To' and 'request
> URI' fields: "t.watson@ieee.org".
> How does the UAC 'guess' if 'ieee.org' refer to a specific 
> host or a domain?
> Looks like according Bis02 para 1.4.2, the UAC tries to get 
> DNS SRV record
> first, and then A record if the former query has failed. Is 
> that true? If
> yes, looks like according the DNS RFC, one may issue a DNS 
> query w/ multiple
> types (e.g. _sip, a, aaaa) and act based on the response.
> Was that the intention of Bis?
> 
> ============================================
> Uri.Baniel@motorola.com, 
> Tel: (847) 632 4616; Fax: (847) 632 3963; 
> ============================================
> 
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

------_=_NextPart_001_01C08B9A.589A1010
Content-Type: text/html;
	charset="ISO-8859-1"
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=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [SIP] Decoding the SIP URL</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I think you clearly reflect the intent of the =
relevant section (1.4.2) in the bis document.&nbsp; Note the =
reservation that you don't try for SRV if the port in the Request-URI =
differs from 5060.</FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Baniel Uri-CUB001 [<A =
HREF=3D"mailto:Uri.Baniel@motorola.com">mailto:Uri.Baniel@motorola.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, January 30, 2001 11:31 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Baniel Uri-CUB001; =
sip@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Dyer William-QA1394; Miller =
Trent-QA1400</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [SIP] Decoding the SIP URL</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; So I guess my question is either just too dumb =
or too boring :(</FONT>
<BR><FONT SIZE=3D2>&gt; Still, is there any good soul on the list, who =
has a moment </FONT>
<BR><FONT SIZE=3D2>&gt; to go over the</FONT>
<BR><FONT SIZE=3D2>&gt; question and respond.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks!</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Uri</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Baniel Uri-CUB001 [<A =
HREF=3D"mailto:Uri_Baniel-CUB001@email.mot.com">mailto:Uri_Baniel-CUB001=
@email.mot.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Sunday, January 28, 2001 6:18 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: sip@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [SIP] Decoding the SIP URL</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Say a UAC gets the following SIP URL from its =
user in the </FONT>
<BR><FONT SIZE=3D2>&gt; 'To' and 'request</FONT>
<BR><FONT SIZE=3D2>&gt; URI' fields: =
&quot;t.watson@ieee.org&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; How does the UAC 'guess' if 'ieee.org' refer to =
a specific </FONT>
<BR><FONT SIZE=3D2>&gt; host or a domain?</FONT>
<BR><FONT SIZE=3D2>&gt; Looks like according Bis02 para 1.4.2, the UAC =
tries to get </FONT>
<BR><FONT SIZE=3D2>&gt; DNS SRV record</FONT>
<BR><FONT SIZE=3D2>&gt; first, and then A record if the former query =
has failed. Is </FONT>
<BR><FONT SIZE=3D2>&gt; that true? If</FONT>
<BR><FONT SIZE=3D2>&gt; yes, looks like according the DNS RFC, one may =
issue a DNS </FONT>
<BR><FONT SIZE=3D2>&gt; query w/ multiple</FONT>
<BR><FONT SIZE=3D2>&gt; types (e.g. _sip, a, aaaa) and act based on the =
response.</FONT>
<BR><FONT SIZE=3D2>&gt; Was that the intention of Bis?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt; Uri.Baniel@motorola.com, </FONT>
<BR><FONT SIZE=3D2>&gt; Tel: (847) 632 4616; Fax: (847) 632 3963; =
</FONT>
<BR><FONT SIZE=3D2>&gt; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; This list is for continuing development of the =
SIP protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; The sip-implementer's list is the place to =
discuss implementation,</FONT>
<BR><FONT SIZE=3D2>&gt; and to receive advice on understanding existing =
sip.</FONT>
<BR><FONT SIZE=3D2>&gt; To subscribe to it, send mail to =
majordomo@cs.columbia.edu with</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;subscribe sip-implementors&quot; in the =
body.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; _______________________________________________<=
/FONT>
<BR><FONT SIZE=3D2>&gt; This list is for continuing development of the =
SIP protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; The sip-implementer's list is the place to =
discuss implementation,</FONT>
<BR><FONT SIZE=3D2>&gt; and to receive advice on understanding existing =
sip.</FONT>
<BR><FONT SIZE=3D2>&gt; To subscribe to it, send mail to =
majordomo@cs.columbia.edu with</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;subscribe sip-implementors&quot; in the =
body.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08B9A.589A1010--

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 11:18:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19031
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 11:18:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 2207D44366; Wed, 31 Jan 2001 10:19:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from miles.dataconnection.com (smtp2.dataconnection.com [192.91.191.8])
	by lists.bell-labs.com (Postfix) with ESMTP id ABB034433A
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 10:18:54 -0500 (EST)
Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2653.19)
	id <DW1K2BYS>; Wed, 31 Jan 2001 16:18:26 -0000
Message-ID: <37701240971DD31193970000F6CCB9F7013EB9D7@duke.datcon.co.uk>
From: SIP Mailing Lists <SIPMailingLists@dataconnection.com>
To: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: [SIP] Are CSeq numbers maintained per calls, or per call leg?
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 16:18:34 -0000

> Can someone please clarify whether CSeq numbers are maintained "per call"
> or "per call leg"?  For example if a UA has two call legs (A and B) in
> place with the same Call-Id and differing To and From values (so one call
> with two call legs), could the UA issue requests as follows (all responses
> etc. have been omitted).
> 
> - Request on A, CSeq = 5 ...
> - Request on A, CSeq = 6 ...
> - Request on B, CSeq = 7 ...
> - Request on A, CSeq = 8 ...
> 
> 
> The following sections from RFC2543bis02 appear to imply that CSeq is
> maintained per call, as my example assumes.
> 
> _6.21 CSeq_
> 
> Consecutive requests that differ in request method, headers or body, but
> have the same Call-ID MUST contain strictly monotonically increasing and
> contiguous sequence numbers; sequence numbers do not wrap around".
> 
> _4.2.6 REGISTER_ states "Call-ID: All registrations from a client SHOULD
> use the same Call-ID header value, at least within the same reboot cycle.
> Cseq: Registrations with the same Call-ID MUST have increasing CSeq header
> values. However, the server does not reject out-of-order requests."
> 
> 
> However the following references seem to imply that CSeq is maintained per
> call leg.
> 
> _RFC2543bis02, F Changes Made in Version 00_
> 
> "Cseq is unique within a call leg, not just within a call (Section 6.21)".
> 
> _SIP FAQ answer to "What is the difference between a call leg and a call
> id?"_
> 
> "The CSeq spaces in the two directions of a call leg are independent.
> Within a single direction, the sequence number is incremented for each
> transaction."
> 
> 
> Therefore, the documentation that I have found seems inconsistent.
> 
> Additionally does any implementation require CSeq to increase
> monotonically per call leg i.e. is there an implementation which would
> reject the final request in my example?
> 
> Thanks,
> Paul DS.
> 
> Paul D.Smith
> Voice Networking Group
> Data Connection Ltd
> Tel:   +44 20 8366 1177
> Fax:   +44 20 8367 8501
> Email: pds@dataconnection.com
> Web:   http://www.dataconnection.com
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 11:25:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19253
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 11:25:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 7BAF04433A; Wed, 31 Jan 2001 10:26:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 9618744336
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 10:25:23 -0500 (EST)
Received: from imop.cisco.com (imop.cisco.com [171.69.11.44])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA06480;
	Wed, 31 Jan 2001 08:25:22 -0800 (PST)
Received: from sony-laptop (rmahy-dsl4.cisco.com [10.19.53.125])
	by imop.cisco.com (Mirapoint)
	with SMTP id AAJ01321;
	Wed, 31 Jan 2001 08:25:06 -0800 (PST)
Message-Id: <4.1.20010131080406.00b509c0@imop.cisco.com>
X-Sender: rmahy@imop.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
To: Ben Campbell <bcampbell@dynamicsoft.com>, "'Rick Dean'" <siplist@fdd.com>,
        Ben Campbell <bcampbell@dynamicsoft.com>
From: Rohan Mahy <rohan@cisco.com>
Subject: RE: [SIP] draft-ietf-sip-handoff-00pre8.txt
Cc: "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F309B1@DYN-TX-EXCH-001.dynam
 icsoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 08:32:43 -0800

Rick Dean wrote:
>> > > We confess, our goal is to build a transfer which works exactly
>> > > like the existing phone system, but happens to use SIP.  When
>> > > we complete this task, feel free to build a phone system
>> > > which works differently.  We hope you find some customers.

A couple years ago we went through the feature books of the leading PBX
brands, and asked the question "What was the customer need behind this
feature?".  For all the user-initiated features, we came up with some
pretty hideous interfaces to invoke these features (that we do not want to
reproduce), but concluded that customers still need/want to setup many of
the same call-leg relationships.

We absolutely want beter ways (UIs) to invoke features (and I have found
customers); we want general primitives instead of a monolithic blob of
"features"; but the customer experience of what happens when someone
invokes the "transfer" thing should be familiar.

Rick is right about one critical element--prompting.  A basic philosophy of
a call is that you get to change your end of the call as much as you like.
The other parties can stay in the call, disconnect, or change their end as
well.  Real-time prompting is not/should not be a part of equation.  Note
that this doesn't have anything to do with the method name.  A prompt for a
REFER is just as scary as a prompt for a HANDOFF.  Rick and Billy didn't
like my REFER Music on Hold flow because it took back a call.  According to
the current philosophy this should be fine in certain
circumstances--without prompting.  If you don't agree that prompting is an
impediment, try turning on manual cookie prompting for about an hour of web
surfing.

We should ask the question, "Why am I asking the user for permission?"  If
wecan come up with default rules of fair play for UA, the user should only
be prompted in extraordinary circumstances, or not at all.

thanks,
-rohan

>> > > Yes, proxies should be able to administratively block
>> > > HANDOFF requests like any other.  Good point.  Do we need another 
>> > > sentence to cover this?  Are you proposing a special header or 
>> > > response code to indicate the proxy and not the end UA blocked it?
>> > > Does it make a difference to the HANDOFF sending UA?
>> > > 
>> > > We already have another method which is "prompt the remote human".
>> > > REFER to a web page does this best.  An audible
>> > > question does not need a SIP extension.  
>> > > 
>> > > Wouldn't the REFER request to a web page need two promptings?  
>> > > The first one is do you want to follow the URL and the 
>> second is the 
>> > > question on the web page.  I can do more damage
>> > > with a HTTP GET than a SIP INVITE, but most browsers follow 
>> > > 302 redirects automatically anyway.
>> > > 
>> > > BTW, I am scared of what
>> > > a REFER with method=REFER prompt would look like to an end
>> > > user.  Clearly, the designers don't intend this.
>> > > 
>> > > Yes, sophisticated UA's with 19" monitors in expert mode will 
>> > > defy the 
>> > > draft and prompt the user.  It is their choice, and the IETF 
>> > > tries hard
>> > > not to mandate this behavior outside the protocol.  Hopefully the 
>> > > UA will prompt after the HANDOFF final response, but before the 
>> > > handoff-status, for timing reasons as you stated.


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 11:33:05 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19438
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 11:33:04 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 19D9844372; Wed, 31 Jan 2001 10:31:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id 5823344372
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 10:30:22 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA02007;
	Wed, 31 Jan 2001 11:33:05 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KJCG7>; Wed, 31 Jan 2001 11:26:37 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BFB98112@DYN-EXCH-001.dynamicsoft.com>
From: Igor Slepchin <ISlepchin@dynamicsoft.com>
To: "'Baniel Uri-CUB001'" <Uri.Baniel@motorola.com>, sip@lists.bell-labs.com
Cc: Dyer William-QA1394 <Bill.Dyer@motorola.com>,
        Miller Trent-QA1400 <Trent.Miller@motorola.com>
Subject: RE: [SIP] Decoding the SIP URL
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 11:26:33 -0500

> -----Original Message-----
> From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com]
> Say a UAC gets the following SIP URL from its user in the 
> 'To' and 'request
> URI' fields: "t.watson@ieee.org".
> How does the UAC 'guess' if 'ieee.org' refer to a specific 
> host or a domain?

What's the difference? The behavior is precisely the same and you quote the
appropriate paragraph from the bis.

---
Igor Slepchin

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 11:38:42 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19552
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 11:38:41 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 8B6F144378; Wed, 31 Jan 2001 10:36:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61])
	by lists.bell-labs.com (Postfix) with ESMTP id 8FE8244364
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 10:35:41 -0500 (EST)
Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com
 (Content Technologies SMTPRS 4.1.5) with ESMTP id <Tc363f43d51721e0a11@cvis29.marconicomms.com>;
 Wed, 31 Jan 2001 16:35:22 +0000
Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP
 (8.8.8+Sun/cvms-30) id QAA24559; Wed, 31 Jan 2001 16:35:22 GMT
Received: by marconicomms.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))  id 802569E5.005B000D ; Wed, 31 Jan 2001 16:33:57 +0000
X-Lotus-FromDomain: MCMAIN@MCEXT
From: "Keith Robinson" <Keith.Robinson@marconi.com>
To: "Joshua Moloney" <jmoloney@nortelnetworks.com>
Cc: sip@lists.bell-labs.com
Message-ID: <802569E5.005AFF8E.00@marconicomms.com>
Subject: Re: [SIP] Overlap call setup
Mime-Version: 1.0
Content-type: multipart/mixed; 
	Boundary="0__=2SjLiOnTumEo2gbYki3aKxrEqWijQPAW6qpFlhh3kWlZcBBb0wxCxFAw"
Content-Disposition: inline
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 16:34:08 +0000

--0__=2SjLiOnTumEo2gbYki3aKxrEqWijQPAW6qpFlhh3kWlZcBBb0wxCxFAw
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



I have recently been trying to get clarification on the implemenation of
overlap sending; see attached for the discussion that has taken place
so far.

Certainly, the mechanism outlined (very sketchily) in RFC2543bis-02 sect 4.2.1
is fundamentally flawed. The Request-URI cannot be used to carry extra digits
as the Record-Route/Route mechanism would end up overwriting the R-URI
and therefore the subsequent digits would be lost.

This then leads to the idea of using the TO field as described in
sip-isup-00-00.txt;
however, I have the following issues with the mechanisms described in this
document :

As the TO field is different on each subsequent INVITE, then it is a new call
leg
on an existing call id; RFC2543bis-02 sect. 11.5 does not state what a UAS
should make of this. If you follow the logic in 11.5 you get to case (3), but
here it only defines the behaviour  if the TO and FROM fields match.

The 484 sent backwards kills that call attempt (but not the state for that
Call-Id -
is this problematic for intermediate proxies ?) so subsequent INVITEs will
actually be initial INVITEs. As these INVITEs must get to the same terminating
UAS,
the originating  UAC will have to create a ROUTE header in an initial INVITE
using ,
at least the CONTACT address from the 484. This implies the use of source
routing, an
issue that I don't believe has been fully resolved, and even if it is and
becomes part
of the base protocol some administrations may be reluctant to admit initial
INVITEs
which try to circumvent their routing policy, so may reject such INVITEs.

Also on the above point, the CONTACT address in the 484 must have the same
semantics as that in a 200 response so that a ROUTE header can be built; however
RFC2543bis-02 sect. 6.14 specifies that a CONTACT address in 4XX responses
indicates a location where additional error information can be found. Indeed, in
a recent
thread entitled Announcements in SIP (401 & 407 Contact) J. Rosenberg believes
that
Record-Route does not make sense in any non-200 response.

I would raise the question of whether the 484 response has any use in overlap
sending
(certainly in the case of ISUP) at all. If a node receives insufficient digits
to decode than it will wait until it receives some more from the preceding node
(or end of
dialling timers mature). If the preceding node receives subsequent digits and
end of dialling
has not been detected then it will pass them on. If the 484 indicated the
minimum number of
digits before a decode could take place, then it would be useful in cutting down
the number
of subseqent messages sent.

Indeed, isup-sip-00.txt does cover the mechanism where a 183 is sent, and not a
484.
The case in point is covered in sect. 11.3 (Example of SIP bridging and overlap
signalling);
However, I have the following issues with this mechanism:

As before relies on source routing.

Relies on proxies sending requests on new call legs but existing call-ids to the
same
downstream server; fine if you administer these proxies, what if you don't ?
(Lots of
wasted IAMs generated). The mechanism should not send 5 (subsequent INVITE)
until it has received an acknowledgement (probably not 100) from the first.
Alternatively,
the Reason-Phrase could detail more specifically the exact progress of the call
("Decoding Address"
in this case ?) so that the ACM is not generated unconditionally.

Sect. 11.2 encourages gateways "to return a183 Session Progress with a Contact
header as soon as they receive an INVITE that they are going to handle and might
contain
an incomplete number". Presumably this is to allow the UAC to build a ROUTE so
that subsequent
INVITEs get to the appropriate UAS. Sect 7.2.3 indicates that a node receiving a
183 prior to generating
an ACM should generate an ACM. Applied together these rules  may cause a prior
node to never
send on any subsequent digits and overlap sending would fail.

I think an approach is required whereby subsequent digits are sent on the same
call leg as the
initial INVITE; either multiple INVITEs are allowed before 200 OK (already
suggested by J. Rosenberg
in a different context) , or the INFO method is used. In both cases the TO field
will have to remain the
same so a new header (or message body type) is required to convey the digits.
Also, replace the 484
with, say, 18X indicating the minimum number of digits required, perhaps in the
Reason-Phrase header.

Regards,

Keith Robinson.






















"Joshua Moloney" <jmoloney@nortelnetworks.com> on 31/01/2001 10:49:33
                                                                                
                                                                                
                                                                                


                                                              
                                                              
                                                              
 To:      sip@lists.bell-labs.com                             
                                                              
 cc:      (bcc: Keith Robinson/MAIN/MC1)                      
                                                              
                                                              
                                                              
 Subject: [SIP] Overlap call setup                            
                                                              







Greetings,

I would like to ask for clarification regarding the implementation of
Overlap.

I'll begin by referring to paragraph 3, section 6.1.2 of
"draft-ietf-isup-sip-00":

It is stated that INVITEs sent after the first one (containing extra digits
in the 'To' field) are to be treated as new Call-Legs, seeing as the
contents of their 'To' headers differ. As such, there is no relationship
between their CSeq values.

If this is the case, how is it possible to ensure correct digit ordering
over an 'unreliable' transport layer like UDP? It would seem logical that
the call originator _would_ use contiguous CSeq values, as it would be
'aware' of the fact that the INVITEs are for the same call.

I believe that this issue was raised on the SIP list on 19 November 1999 by
Gonzalo C and Jonathan R. The subject of the messages was "Re: Comments on
draft-camarillo-mmusic-sip-isup-bcp-00.txt". The outcome of the exchange
appeared to be an agreement that CSeq ordering should be employed.

However, does this in any way imply that under such circumstances the
INVITEs would/should belong to the same Call-Leg? After all, the concept of
Overlap does not seem to 'fit in' with the concept behind multiple Call-Legs
anyway.

If there has been a change in thinking behind the problem, and the latest
draft is correct, please could you explain how the ordering problem will be
overcome. If not, perhaps the draft needs modification to include these
considerations...


Regards,

Josh Moloney


--0__=2SjLiOnTumEo2gbYki3aKxrEqWijQPAW6qpFlhh3kWlZcBBb0wxCxFAw
Content-type: text/html; 
	name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PVVTLUFTQ0lJIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i
TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTIuMzUiPg0KPFRJVExFPk92ZXJsYXAg
Y2FsbCBzZXR1cDwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgU0laRT0yIEZB
Q0U9IkFyaWFsIj5HcmVldGluZ3MsPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPkkgd291bGQgbGlrZSB0byBhc2sgZm9yIGNsYXJpZmljYXRpb24gcmVnYXJkaW5n
IHRoZSBpbXBsZW1lbnRhdGlvbiBvZiBPdmVybGFwLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQg
U0laRT0yIEZBQ0U9IkFyaWFsIj5JJ2xsIGJlZ2luIGJ5IHJlZmVycmluZyB0byBwYXJhZ3JhcGgg
Mywgc2VjdGlvbiA2LjEuMiBvZiAmcXVvdDtkcmFmdC1pZXRmLWlzdXAtc2lwLTAwJnF1b3Q7Ojwv
Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JdCBpcyBzdGF0ZWQg
dGhhdCBJTlZJVEVzIHNlbnQgYWZ0ZXIgdGhlIGZpcnN0IG9uZSAoY29udGFpbmluZyBleHRyYSBk
aWdpdHMgaW4gdGhlICdUbycgZmllbGQpIGFyZSB0byBiZSB0cmVhdGVkIGFzIG5ldyBDYWxsLUxl
Z3MsIHNlZWluZyBhcyB0aGUgY29udGVudHMgb2YgdGhlaXIgJ1RvJyBoZWFkZXJzIGRpZmZlci4g
QXMgc3VjaCwgdGhlcmUgaXMgbm8gcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlaXIgQ1NlcSB2YWx1
ZXMuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JZiB0aGlzIGlz
IHRoZSBjYXNlLCBob3cgaXMgaXQgcG9zc2libGUgdG8gZW5zdXJlIGNvcnJlY3QgZGlnaXQgb3Jk
ZXJpbmcgb3ZlciBhbiAndW5yZWxpYWJsZScgdHJhbnNwb3J0IGxheWVyIGxpa2UgVURQPyBJdCB3
b3VsZCBzZWVtIGxvZ2ljYWwgdGhhdCB0aGUgY2FsbCBvcmlnaW5hdG9yIF93b3VsZF8gdXNlIGNv
bnRpZ3VvdXMgQ1NlcSB2YWx1ZXMsIGFzIGl0IHdvdWxkIGJlICdhd2FyZScgb2YgdGhlIGZhY3Qg
dGhhdCB0aGUgSU5WSVRFcyBhcmUgZm9yIHRoZSBzYW1lIGNhbGwuPC9GT05UPjwvUD4NCg0KPFA+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JIGJlbGlldmUgdGhhdCB0aGlzIGlzc3VlIHdhcyBy
YWlzZWQgb24gdGhlIFNJUCBsaXN0IG9uIDE5IE5vdmVtYmVyIDE5OTkgYnkgR29uemFsbyBDIGFu
ZCBKb25hdGhhbiBSLiBUaGUgc3ViamVjdCBvZiB0aGUgbWVzc2FnZXMgd2FzICZxdW90O1JlOiBD
b21tZW50cyBvbiBkcmFmdC1jYW1hcmlsbG8tbW11c2ljLXNpcC1pc3VwLWJjcC0wMC50eHQmcXVv
dDsuIFRoZSBvdXRjb21lIG9mIHRoZSBleGNoYW5nZSBhcHBlYXJlZCB0byBiZSBhbiBhZ3JlZW1l
bnQgdGhhdCBDU2VxIG9yZGVyaW5nIHNob3VsZCBiZSBlbXBsb3llZC48L0ZPTlQ+PC9QPg0KDQo8
UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkhvd2V2ZXIsIGRvZXMgdGhpcyBpbiBhbnkgd2F5
IGltcGx5IHRoYXQgdW5kZXIgc3VjaCBjaXJjdW1zdGFuY2VzIHRoZSBJTlZJVEVzIHdvdWxkL3No
b3VsZCBiZWxvbmcgdG8gdGhlIHNhbWUgQ2FsbC1MZWc/IEFmdGVyIGFsbCwgdGhlIGNvbmNlcHQg
b2YgT3ZlcmxhcCBkb2VzIG5vdCBzZWVtIHRvICdmaXQgaW4nIHdpdGggdGhlIGNvbmNlcHQgYmVo
aW5kIG11bHRpcGxlIENhbGwtTGVncyBhbnl3YXkuPC9GT05UPjwvUD4NCg0KPFA+PEZPTlQgU0la
RT0yIEZBQ0U9IkFyaWFsIj5JZiB0aGVyZSBoYXMgYmVlbiBhIGNoYW5nZSBpbiB0aGlua2luZyBi
ZWhpbmQgdGhlIHByb2JsZW0sIGFuZCB0aGUgbGF0ZXN0IGRyYWZ0IGlzIGNvcnJlY3QsIHBsZWFz
ZSBjb3VsZCB5b3UgZXhwbGFpbiBob3cgdGhlIG9yZGVyaW5nIHByb2JsZW0gd2lsbCBiZSBvdmVy
Y29tZS4gSWYgbm90LCBwZXJoYXBzIHRoZSBkcmFmdCBuZWVkcyBtb2RpZmljYXRpb24gdG8gaW5j
bHVkZSB0aGVzZSBjb25zaWRlcmF0aW9ucy4uLjwvRk9OVD48L1A+DQo8QlI+DQoNCjxQPjxGT05U
IFNJWkU9MiBGQUNFPSJBcmlhbCI+UmVnYXJkcyw8L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJ
WkU9MiBGQUNFPSJBcmlhbCI+Sm9zaCBNb2xvbmV5PC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8
L0hUTUw+

--0__=2SjLiOnTumEo2gbYki3aKxrEqWijQPAW6qpFlhh3kWlZcBBb0wxCxFAw--


_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 12:22:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20545
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 12:22:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id B92F244365; Wed, 31 Jan 2001 11:23:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by lists.bell-labs.com (Postfix) with ESMTP id 8A9694435F
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 11:22:29 -0500 (EST)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 31 Jan 2001 12:21:50 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <D33PHAG6>; Wed, 31 Jan 2001 12:21:48 -0500
Message-ID: <28560036253BD41191A10000F8BCBD110389F157@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: laks hmi <lakshmiam@yahoo.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Regarding header in SIP-URL
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08BAA.46680FE0"
X-Orig: <taylor@americasm01.nt.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 12:21:40 -0500

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_01C08BAA.46680FE0
Content-Type: text/plain;
	charset="ISO-8859-1"

Not according to the ABNF.  Looking at it logically, no header defined so
far has the nature of a keyword whose very presence conveys useful
information.  Hence it will be present with empty value only to say exactly
that.  hname "=" says that there is nothing there more clearly than just
hname.

> -----Original Message-----
> From: laks hmi [mailto:lakshmiam@yahoo.com]
> Sent: Wednesday, January 31, 2001 3:45 AM
> To: sip@lists.bell-labs.com
> Subject: [SIP] Regarding header in SIP-URL
> 
> 
> Hi All,
> 
> In SIP-URL, header = hname "=" hvalue.
> Here hvalue can be zero or more, so in the
> case of zero characters "=" character is not needed
> So can i put header = hname [ "=" hvalue].
> 
> 
> Regards
> lakshmi
> 
> 
> __________________________________________________
> Get personalized email addresses from Yahoo! Mail - only $35 
> a year!  http://personal.mail.yahoo.com/
> 
> _______________________________________________
> This list is for continuing development of the SIP protocol.
> The sip-implementer's list is the place to discuss implementation,
> and to receive advice on understanding existing sip.
> To subscribe to it, send mail to majordomo@cs.columbia.edu with
> "subscribe sip-implementors" in the body.
> 

------_=_NextPart_001_01C08BAA.46680FE0
Content-Type: text/html;
	charset="ISO-8859-1"
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=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [SIP] Regarding header in SIP-URL</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Not according to the ABNF.&nbsp; Looking at it =
logically, no header defined so far has the nature of a keyword whose =
very presence conveys useful information.&nbsp; Hence it will be =
present with empty value only to say exactly that.&nbsp; hname =
&quot;=3D&quot; says that there is nothing there more clearly than just =
hname.</FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: laks hmi [<A =
HREF=3D"mailto:lakshmiam@yahoo.com">mailto:lakshmiam@yahoo.com</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, January 31, 2001 3:45 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: sip@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: [SIP] Regarding header in =
SIP-URL</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi All,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In SIP-URL, header =3D hname &quot;=3D&quot; =
hvalue.</FONT>
<BR><FONT SIZE=3D2>&gt; Here hvalue can be zero or more, so in =
the</FONT>
<BR><FONT SIZE=3D2>&gt; case of zero characters &quot;=3D&quot; =
character is not needed</FONT>
<BR><FONT SIZE=3D2>&gt; So can i put header =3D hname [ &quot;=3D&quot; =
hvalue].</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards</FONT>
<BR><FONT SIZE=3D2>&gt; lakshmi</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
__________________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; Get personalized email addresses from Yahoo! =
Mail - only $35 </FONT>
<BR><FONT SIZE=3D2>&gt; a year!&nbsp; <A =
HREF=3D"http://personal.mail.yahoo.com/" =
TARGET=3D"_blank">http://personal.mail.yahoo.com/</A></FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
_______________________________________________</FONT>
<BR><FONT SIZE=3D2>&gt; This list is for continuing development of the =
SIP protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; The sip-implementer's list is the place to =
discuss implementation,</FONT>
<BR><FONT SIZE=3D2>&gt; and to receive advice on understanding existing =
sip.</FONT>
<BR><FONT SIZE=3D2>&gt; To subscribe to it, send mail to =
majordomo@cs.columbia.edu with</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;subscribe sip-implementors&quot; in the =
body.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08BAA.46680FE0--

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 13:34:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22849
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 13:34:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E03CD44342; Wed, 31 Jan 2001 12:35:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57])
	by lists.bell-labs.com (Postfix) with ESMTP id C3D7D4433A
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 12:34:25 -0500 (EST)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 31 Jan 2001 13:32:25 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) 
          id <D33PHCWC>; Wed, 31 Jan 2001 13:31:22 -0500
Message-ID: <28560036253BD41191A10000F8BCBD11038E3350@zcard00g.ca.nortel.com>
From: "Tom-PT Taylor" <taylor@nortelnetworks.com>
To: Keith Robinson <Keith.Robinson@marconi.com>
Cc: sip@lists.bell-labs.com, "Joshua Moloney" <jmoloney@nortelnetworks.com>
Subject: RE: [SIP] Overlap call setup
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C08BB3.FC5946D0"
X-Orig: <taylor@americasm01.nt.com>
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 13:31:11 -0500

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_01C08BB3.FC5946D0
Content-Type: text/plain;
	charset="ISO-8859-1"

I think you've made one assumption I might question.  Assuming that
subsequent INVITEs are being sent, containing all of the digits so far
collected, so that they are self-contained: why is it necessary that each
ends up at the same UAS?  When the 484 is sent back, call state should be
cleared all along the path, even in the SIP-UAC side of the ingress gateway.
Only the ISUP side of that gateway and, I suppose, the ISUP-SIP interworking
function, should retain call state.

> -----Original Message-----
> From: Keith Robinson [mailto:Keith.Robinson@marconi.com]
> Sent: Wednesday, January 31, 2001 11:34 AM
> To: Moloney, Joshua [MDN05:CT07:EXCH]
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] Overlap call setup
> 
> 
> 
> 
> I have recently been trying to get clarification on the 
> implemenation of
> overlap sending; see attached for the discussion that has taken place
> so far.
> 
> Certainly, the mechanism outlined (very sketchily) in 
> RFC2543bis-02 sect 4.2.1
> is fundamentally flawed. The Request-URI cannot be used to 
> carry extra digits
> as the Record-Route/Route mechanism would end up overwriting the R-URI
> and therefore the subsequent digits would be lost.
> 
> This then leads to the idea of using the TO field as described in
> sip-isup-00-00.txt;
> however, I have the following issues with the mechanisms 
> described in this
> document :
> 
> As the TO field is different on each subsequent INVITE, then 
> it is a new call
> leg
> on an existing call id; RFC2543bis-02 sect. 11.5 does not 
> state what a UAS
> should make of this. If you follow the logic in 11.5 you get 
> to case (3), but
> here it only defines the behaviour  if the TO and FROM fields match.
> 
> The 484 sent backwards kills that call attempt (but not the 
> state for that
> Call-Id -
> is this problematic for intermediate proxies ?) so subsequent 
> INVITEs will
> actually be initial INVITEs. As these INVITEs must get to the 
> same terminating
> UAS,
> the originating  UAC will have to create a ROUTE header in an 
> initial INVITE
> using ,
> at least the CONTACT address from the 484. This implies the 
> use of source
> routing, an
> issue that I don't believe has been fully resolved, and even 
> if it is and
> becomes part
> of the base protocol some administrations may be reluctant to 
> admit initial
> INVITEs
> which try to circumvent their routing policy, so may reject 
> such INVITEs.
> 
> Also on the above point, the CONTACT address in the 484 must 
> have the same
> semantics as that in a 200 response so that a ROUTE header 
> can be built; however
> RFC2543bis-02 sect. 6.14 specifies that a CONTACT address in 
> 4XX responses
> indicates a location where additional error information can 
> be found. Indeed, in
> a recent
> thread entitled Announcements in SIP (401 & 407 Contact) J. 
> Rosenberg believes
> that
> Record-Route does not make sense in any non-200 response.
> 
> I would raise the question of whether the 484 response has 
> any use in overlap
> sending
> (certainly in the case of ISUP) at all. If a node receives 
> insufficient digits
> to decode than it will wait until it receives some more from 
> the preceding node
> (or end of
> dialling timers mature). If the preceding node receives 
> subsequent digits and
> end of dialling
> has not been detected then it will pass them on. If the 484 
> indicated the
> minimum number of
> digits before a decode could take place, then it would be 
> useful in cutting down
> the number
> of subseqent messages sent.
> 
> Indeed, isup-sip-00.txt does cover the mechanism where a 183 
> is sent, and not a
> 484.
> The case in point is covered in sect. 11.3 (Example of SIP 
> bridging and overlap
> signalling);
> However, I have the following issues with this mechanism:
> 
> As before relies on source routing.
> 
> Relies on proxies sending requests on new call legs but 
> existing call-ids to the
> same
> downstream server; fine if you administer these proxies, what 
> if you don't ?
> (Lots of
> wasted IAMs generated). The mechanism should not send 5 
> (subsequent INVITE)
> until it has received an acknowledgement (probably not 100) 
> from the first.
> Alternatively,
> the Reason-Phrase could detail more specifically the exact 
> progress of the call
> ("Decoding Address"
> in this case ?) so that the ACM is not generated unconditionally.
> 
> Sect. 11.2 encourages gateways "to return a183 Session 
> Progress with a Contact
> header as soon as they receive an INVITE that they are going 
> to handle and might
> contain
> an incomplete number". Presumably this is to allow the UAC to 
> build a ROUTE so
> that subsequent
> INVITEs get to the appropriate UAS. Sect 7.2.3 indicates that 
> a node receiving a
> 183 prior to generating
> an ACM should generate an ACM. Applied together these rules  
> may cause a prior
> node to never
> send on any subsequent digits and overlap sending would fail.
> 
> I think an approach is required whereby subsequent digits are 
> sent on the same
> call leg as the
> initial INVITE; either multiple INVITEs are allowed before 
> 200 OK (already
> suggested by J. Rosenberg
> in a different context) , or the INFO method is used. In both 
> cases the TO field
> will have to remain the
> same so a new header (or message body type) is required to 
> convey the digits.
> Also, replace the 484
> with, say, 18X indicating the minimum number of digits 
> required, perhaps in the
> Reason-Phrase header.
> 
> Regards,
> 
> Keith Robinson.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> "Joshua Moloney" <jmoloney@nortelnetworks.com> on 31/01/2001 10:49:33
>                                                               
>                   
>                                                               
>                   
>                                                               
>                   
> 
> 
>                                                               
>                                                               
>                                                               
>  To:      sip@lists.bell-labs.com                             
>                                                               
>  cc:      (bcc: Keith Robinson/MAIN/MC1)                      
>                                                               
>                                                               
>                                                               
>  Subject: [SIP] Overlap call setup                            
>                                                               
> 
> 
> 
> 
> 
> 
> 
> Greetings,
> 
> I would like to ask for clarification regarding the implementation of
> Overlap.
> 
> I'll begin by referring to paragraph 3, section 6.1.2 of
> "draft-ietf-isup-sip-00":
> 
> It is stated that INVITEs sent after the first one 
> (containing extra digits
> in the 'To' field) are to be treated as new Call-Legs, seeing as the
> contents of their 'To' headers differ. As such, there is no 
> relationship
> between their CSeq values.
> 
> If this is the case, how is it possible to ensure correct 
> digit ordering
> over an 'unreliable' transport layer like UDP? It would seem 
> logical that
> the call originator _would_ use contiguous CSeq values, as it would be
> 'aware' of the fact that the INVITEs are for the same call.
> 
> I believe that this issue was raised on the SIP list on 19 
> November 1999 by
> Gonzalo C and Jonathan R. The subject of the messages was 
> "Re: Comments on
> draft-camarillo-mmusic-sip-isup-bcp-00.txt". The outcome of 
> the exchange
> appeared to be an agreement that CSeq ordering should be employed.
> 
> However, does this in any way imply that under such circumstances the
> INVITEs would/should belong to the same Call-Leg? After all, 
> the concept of
> Overlap does not seem to 'fit in' with the concept behind 
> multiple Call-Legs
> anyway.
> 
> If there has been a change in thinking behind the problem, 
> and the latest
> draft is correct, please could you explain how the ordering 
> problem will be
> overcome. If not, perhaps the draft needs modification to 
> include these
> considerations...
> 
> 
> Regards,
> 
> Josh Moloney
> 
> 

------_=_NextPart_001_01C08BB3.FC5946D0
Content-Type: text/html;
	charset="ISO-8859-1"
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=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: [SIP] Overlap call setup</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I think you've made one assumption I might =
question.&nbsp; Assuming that subsequent INVITEs are being sent, =
containing all of the digits so far collected, so that they are =
self-contained: why is it necessary that each ends up at the same =
UAS?&nbsp; When the 484 is sent back, call state should be cleared all =
along the path, even in the SIP-UAC side of the ingress gateway.&nbsp; =
Only the ISUP side of that gateway and, I suppose, the ISUP-SIP =
interworking function, should retain call state.</FONT></P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Keith Robinson [<A =
HREF=3D"mailto:Keith.Robinson@marconi.com">mailto:Keith.Robinson@marconi=
.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, January 31, 2001 11:34 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Moloney, Joshua [MDN05:CT07:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: sip@lists.bell-labs.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [SIP] Overlap call setup</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I have recently been trying to get =
clarification on the </FONT>
<BR><FONT SIZE=3D2>&gt; implemenation of</FONT>
<BR><FONT SIZE=3D2>&gt; overlap sending; see attached for the =
discussion that has taken place</FONT>
<BR><FONT SIZE=3D2>&gt; so far.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Certainly, the mechanism outlined (very =
sketchily) in </FONT>
<BR><FONT SIZE=3D2>&gt; RFC2543bis-02 sect 4.2.1</FONT>
<BR><FONT SIZE=3D2>&gt; is fundamentally flawed. The Request-URI cannot =
be used to </FONT>
<BR><FONT SIZE=3D2>&gt; carry extra digits</FONT>
<BR><FONT SIZE=3D2>&gt; as the Record-Route/Route mechanism would end =
up overwriting the R-URI</FONT>
<BR><FONT SIZE=3D2>&gt; and therefore the subsequent digits would be =
lost.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This then leads to the idea of using the TO =
field as described in</FONT>
<BR><FONT SIZE=3D2>&gt; sip-isup-00-00.txt;</FONT>
<BR><FONT SIZE=3D2>&gt; however, I have the following issues with the =
mechanisms </FONT>
<BR><FONT SIZE=3D2>&gt; described in this</FONT>
<BR><FONT SIZE=3D2>&gt; document :</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As the TO field is different on each subsequent =
INVITE, then </FONT>
<BR><FONT SIZE=3D2>&gt; it is a new call</FONT>
<BR><FONT SIZE=3D2>&gt; leg</FONT>
<BR><FONT SIZE=3D2>&gt; on an existing call id; RFC2543bis-02 sect. =
11.5 does not </FONT>
<BR><FONT SIZE=3D2>&gt; state what a UAS</FONT>
<BR><FONT SIZE=3D2>&gt; should make of this. If you follow the logic in =
11.5 you get </FONT>
<BR><FONT SIZE=3D2>&gt; to case (3), but</FONT>
<BR><FONT SIZE=3D2>&gt; here it only defines the behaviour&nbsp; if the =
TO and FROM fields match.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The 484 sent backwards kills that call attempt =
(but not the </FONT>
<BR><FONT SIZE=3D2>&gt; state for that</FONT>
<BR><FONT SIZE=3D2>&gt; Call-Id -</FONT>
<BR><FONT SIZE=3D2>&gt; is this problematic for intermediate proxies ?) =
so subsequent </FONT>
<BR><FONT SIZE=3D2>&gt; INVITEs will</FONT>
<BR><FONT SIZE=3D2>&gt; actually be initial INVITEs. As these INVITEs =
must get to the </FONT>
<BR><FONT SIZE=3D2>&gt; same terminating</FONT>
<BR><FONT SIZE=3D2>&gt; UAS,</FONT>
<BR><FONT SIZE=3D2>&gt; the originating&nbsp; UAC will have to create a =
ROUTE header in an </FONT>
<BR><FONT SIZE=3D2>&gt; initial INVITE</FONT>
<BR><FONT SIZE=3D2>&gt; using ,</FONT>
<BR><FONT SIZE=3D2>&gt; at least the CONTACT address from the 484. This =
implies the </FONT>
<BR><FONT SIZE=3D2>&gt; use of source</FONT>
<BR><FONT SIZE=3D2>&gt; routing, an</FONT>
<BR><FONT SIZE=3D2>&gt; issue that I don't believe has been fully =
resolved, and even </FONT>
<BR><FONT SIZE=3D2>&gt; if it is and</FONT>
<BR><FONT SIZE=3D2>&gt; becomes part</FONT>
<BR><FONT SIZE=3D2>&gt; of the base protocol some administrations may =
be reluctant to </FONT>
<BR><FONT SIZE=3D2>&gt; admit initial</FONT>
<BR><FONT SIZE=3D2>&gt; INVITEs</FONT>
<BR><FONT SIZE=3D2>&gt; which try to circumvent their routing policy, =
so may reject </FONT>
<BR><FONT SIZE=3D2>&gt; such INVITEs.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Also on the above point, the CONTACT address in =
the 484 must </FONT>
<BR><FONT SIZE=3D2>&gt; have the same</FONT>
<BR><FONT SIZE=3D2>&gt; semantics as that in a 200 response so that a =
ROUTE header </FONT>
<BR><FONT SIZE=3D2>&gt; can be built; however</FONT>
<BR><FONT SIZE=3D2>&gt; RFC2543bis-02 sect. 6.14 specifies that a =
CONTACT address in </FONT>
<BR><FONT SIZE=3D2>&gt; 4XX responses</FONT>
<BR><FONT SIZE=3D2>&gt; indicates a location where additional error =
information can </FONT>
<BR><FONT SIZE=3D2>&gt; be found. Indeed, in</FONT>
<BR><FONT SIZE=3D2>&gt; a recent</FONT>
<BR><FONT SIZE=3D2>&gt; thread entitled Announcements in SIP (401 &amp; =
407 Contact) J. </FONT>
<BR><FONT SIZE=3D2>&gt; Rosenberg believes</FONT>
<BR><FONT SIZE=3D2>&gt; that</FONT>
<BR><FONT SIZE=3D2>&gt; Record-Route does not make sense in any non-200 =
response.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I would raise the question of whether the 484 =
response has </FONT>
<BR><FONT SIZE=3D2>&gt; any use in overlap</FONT>
<BR><FONT SIZE=3D2>&gt; sending</FONT>
<BR><FONT SIZE=3D2>&gt; (certainly in the case of ISUP) at all. If a =
node receives </FONT>
<BR><FONT SIZE=3D2>&gt; insufficient digits</FONT>
<BR><FONT SIZE=3D2>&gt; to decode than it will wait until it receives =
some more from </FONT>
<BR><FONT SIZE=3D2>&gt; the preceding node</FONT>
<BR><FONT SIZE=3D2>&gt; (or end of</FONT>
<BR><FONT SIZE=3D2>&gt; dialling timers mature). If the preceding node =
receives </FONT>
<BR><FONT SIZE=3D2>&gt; subsequent digits and</FONT>
<BR><FONT SIZE=3D2>&gt; end of dialling</FONT>
<BR><FONT SIZE=3D2>&gt; has not been detected then it will pass them =
on. If the 484 </FONT>
<BR><FONT SIZE=3D2>&gt; indicated the</FONT>
<BR><FONT SIZE=3D2>&gt; minimum number of</FONT>
<BR><FONT SIZE=3D2>&gt; digits before a decode could take place, then =
it would be </FONT>
<BR><FONT SIZE=3D2>&gt; useful in cutting down</FONT>
<BR><FONT SIZE=3D2>&gt; the number</FONT>
<BR><FONT SIZE=3D2>&gt; of subseqent messages sent.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Indeed, isup-sip-00.txt does cover the =
mechanism where a 183 </FONT>
<BR><FONT SIZE=3D2>&gt; is sent, and not a</FONT>
<BR><FONT SIZE=3D2>&gt; 484.</FONT>
<BR><FONT SIZE=3D2>&gt; The case in point is covered in sect. 11.3 =
(Example of SIP </FONT>
<BR><FONT SIZE=3D2>&gt; bridging and overlap</FONT>
<BR><FONT SIZE=3D2>&gt; signalling);</FONT>
<BR><FONT SIZE=3D2>&gt; However, I have the following issues with this =
mechanism:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As before relies on source routing.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Relies on proxies sending requests on new call =
legs but </FONT>
<BR><FONT SIZE=3D2>&gt; existing call-ids to the</FONT>
<BR><FONT SIZE=3D2>&gt; same</FONT>
<BR><FONT SIZE=3D2>&gt; downstream server; fine if you administer these =
proxies, what </FONT>
<BR><FONT SIZE=3D2>&gt; if you don't ?</FONT>
<BR><FONT SIZE=3D2>&gt; (Lots of</FONT>
<BR><FONT SIZE=3D2>&gt; wasted IAMs generated). The mechanism should =
not send 5 </FONT>
<BR><FONT SIZE=3D2>&gt; (subsequent INVITE)</FONT>
<BR><FONT SIZE=3D2>&gt; until it has received an acknowledgement =
(probably not 100) </FONT>
<BR><FONT SIZE=3D2>&gt; from the first.</FONT>
<BR><FONT SIZE=3D2>&gt; Alternatively,</FONT>
<BR><FONT SIZE=3D2>&gt; the Reason-Phrase could detail more =
specifically the exact </FONT>
<BR><FONT SIZE=3D2>&gt; progress of the call</FONT>
<BR><FONT SIZE=3D2>&gt; (&quot;Decoding Address&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; in this case ?) so that the ACM is not =
generated unconditionally.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sect. 11.2 encourages gateways &quot;to return =
a183 Session </FONT>
<BR><FONT SIZE=3D2>&gt; Progress with a Contact</FONT>
<BR><FONT SIZE=3D2>&gt; header as soon as they receive an INVITE that =
they are going </FONT>
<BR><FONT SIZE=3D2>&gt; to handle and might</FONT>
<BR><FONT SIZE=3D2>&gt; contain</FONT>
<BR><FONT SIZE=3D2>&gt; an incomplete number&quot;. Presumably this is =
to allow the UAC to </FONT>
<BR><FONT SIZE=3D2>&gt; build a ROUTE so</FONT>
<BR><FONT SIZE=3D2>&gt; that subsequent</FONT>
<BR><FONT SIZE=3D2>&gt; INVITEs get to the appropriate UAS. Sect 7.2.3 =
indicates that </FONT>
<BR><FONT SIZE=3D2>&gt; a node receiving a</FONT>
<BR><FONT SIZE=3D2>&gt; 183 prior to generating</FONT>
<BR><FONT SIZE=3D2>&gt; an ACM should generate an ACM. Applied together =
these rules&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; may cause a prior</FONT>
<BR><FONT SIZE=3D2>&gt; node to never</FONT>
<BR><FONT SIZE=3D2>&gt; send on any subsequent digits and overlap =
sending would fail.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I think an approach is required whereby =
subsequent digits are </FONT>
<BR><FONT SIZE=3D2>&gt; sent on the same</FONT>
<BR><FONT SIZE=3D2>&gt; call leg as the</FONT>
<BR><FONT SIZE=3D2>&gt; initial INVITE; either multiple INVITEs are =
allowed before </FONT>
<BR><FONT SIZE=3D2>&gt; 200 OK (already</FONT>
<BR><FONT SIZE=3D2>&gt; suggested by J. Rosenberg</FONT>
<BR><FONT SIZE=3D2>&gt; in a different context) , or the INFO method is =
used. In both </FONT>
<BR><FONT SIZE=3D2>&gt; cases the TO field</FONT>
<BR><FONT SIZE=3D2>&gt; will have to remain the</FONT>
<BR><FONT SIZE=3D2>&gt; same so a new header (or message body type) is =
required to </FONT>
<BR><FONT SIZE=3D2>&gt; convey the digits.</FONT>
<BR><FONT SIZE=3D2>&gt; Also, replace the 484</FONT>
<BR><FONT SIZE=3D2>&gt; with, say, 18X indicating the minimum number of =
digits </FONT>
<BR><FONT SIZE=3D2>&gt; required, perhaps in the</FONT>
<BR><FONT SIZE=3D2>&gt; Reason-Phrase header.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Keith Robinson.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;Joshua Moloney&quot; =
&lt;jmoloney@nortelnetworks.com&gt; on 31/01/2001 10:49:33</FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; To:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
sip@lists.bell-labs.com&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; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; cc:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (bcc: =
Keith =
Robinson/MAIN/MC1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; Subject: [SIP] Overlap call =
setup&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; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Greetings,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I would like to ask for clarification regarding =
the implementation of</FONT>
<BR><FONT SIZE=3D2>&gt; Overlap.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I'll begin by referring to paragraph 3, section =
6.1.2 of</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;draft-ietf-isup-sip-00&quot;:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It is stated that INVITEs sent after the first =
one </FONT>
<BR><FONT SIZE=3D2>&gt; (containing extra digits</FONT>
<BR><FONT SIZE=3D2>&gt; in the 'To' field) are to be treated as new =
Call-Legs, seeing as the</FONT>
<BR><FONT SIZE=3D2>&gt; contents of their 'To' headers differ. As such, =
there is no </FONT>
<BR><FONT SIZE=3D2>&gt; relationship</FONT>
<BR><FONT SIZE=3D2>&gt; between their CSeq values.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If this is the case, how is it possible to =
ensure correct </FONT>
<BR><FONT SIZE=3D2>&gt; digit ordering</FONT>
<BR><FONT SIZE=3D2>&gt; over an 'unreliable' transport layer like UDP? =
It would seem </FONT>
<BR><FONT SIZE=3D2>&gt; logical that</FONT>
<BR><FONT SIZE=3D2>&gt; the call originator _would_ use contiguous CSeq =
values, as it would be</FONT>
<BR><FONT SIZE=3D2>&gt; 'aware' of the fact that the INVITEs are for =
the same call.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I believe that this issue was raised on the SIP =
list on 19 </FONT>
<BR><FONT SIZE=3D2>&gt; November 1999 by</FONT>
<BR><FONT SIZE=3D2>&gt; Gonzalo C and Jonathan R. The subject of the =
messages was </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;Re: Comments on</FONT>
<BR><FONT SIZE=3D2>&gt; =
draft-camarillo-mmusic-sip-isup-bcp-00.txt&quot;. The outcome of =
</FONT>
<BR><FONT SIZE=3D2>&gt; the exchange</FONT>
<BR><FONT SIZE=3D2>&gt; appeared to be an agreement that CSeq ordering =
should be employed.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; However, does this in any way imply that under =
such circumstances the</FONT>
<BR><FONT SIZE=3D2>&gt; INVITEs would/should belong to the same =
Call-Leg? After all, </FONT>
<BR><FONT SIZE=3D2>&gt; the concept of</FONT>
<BR><FONT SIZE=3D2>&gt; Overlap does not seem to 'fit in' with the =
concept behind </FONT>
<BR><FONT SIZE=3D2>&gt; multiple Call-Legs</FONT>
<BR><FONT SIZE=3D2>&gt; anyway.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If there has been a change in thinking behind =
the problem, </FONT>
<BR><FONT SIZE=3D2>&gt; and the latest</FONT>
<BR><FONT SIZE=3D2>&gt; draft is correct, please could you explain how =
the ordering </FONT>
<BR><FONT SIZE=3D2>&gt; problem will be</FONT>
<BR><FONT SIZE=3D2>&gt; overcome. If not, perhaps the draft needs =
modification to </FONT>
<BR><FONT SIZE=3D2>&gt; include these</FONT>
<BR><FONT SIZE=3D2>&gt; considerations...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Josh Moloney</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C08BB3.FC5946D0--

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 13:42:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23070
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 13:42:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id C397344361; Wed, 31 Jan 2001 12:43:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id DAC734433C
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 12:42:45 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA04285;
	Wed, 31 Jan 2001 13:45:25 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KJCY4>; Wed, 31 Jan 2001 13:38:57 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB288@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Ngo, Dai'" <c-Dai.Ngo@WCOM.Com>,
        "'sip@lists.bell-labs.com'" <sip@lists.bell-labs.com>
Subject: RE: [SIP] Feature="voice-mail" v.s Feature="voicemai"
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 13:38:50 -0500


  
-----Original Message-----
>From: Ngo, Dai [mailto:c-Dai.Ngo@WCOM.Com]
>Sent: Tuesday, January 16, 2001 9:43 AM
>To: 'sip@lists.bell-labs.com'
>Subject: [SIP] Feature="voice-mail" v.s Feature="voicemai"
>
>
>Hi all, 
>I ran across another question and would like to hear other's opinion. 
>On page 4 of the draft-ietf-sip-callerprefs-03.txt, it says,
feature-value="voice-mail" 
>(with a hyphen between voice and mail). On page 1 and 2 of
draft-mahy-sip-message-waiting-
>00.txt it says feature="voicemail" (without a hyphen). Which way should I
use? 
>Thanks, 
>Dai Ngo

Not sure if I had answered this... really behind on sip mail.

The answer is that the caller preferences spec is definitive. 

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 13:47:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23157
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 13:47:54 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D980444378; Wed, 31 Jan 2001 12:48:04 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id D88D54433C
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 12:47:15 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA04389;
	Wed, 31 Jan 2001 13:49:50 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KJCZP>; Wed, 31 Jan 2001 13:43:22 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB289@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'Henning G. Schulzrinne'" <hgs@cs.columbia.edu>,
        Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'Grant McSheffrey'" <grant.mcsheffrey@empowertel.com>,
        Sip List <sip@lists.bell-labs.com>
Subject: RE: [SIP] Timestamp header
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 13:43:16 -0500



 

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Tuesday, January 16, 2001 10:25 AM
> To: Jonathan Rosenberg
> Cc: 'Grant McSheffrey'; Sip List
> Subject: Re: [SIP] Timestamp header
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > The spec is not clear on this, saying simply that it should 
> be echoed. I
> > would imagine placing it in all responses, provisional and 
> final, makes the
> > most sense.
> 
> Note that because of the different origins, the delay for the 100 may
> differ from the other 1xx and the final response.

Hmm. This brings up some more issues.

If the purpose of the Timestamp header is to determine RTT for
retransmission rates, then what you really want is the delay between the UAC
and the *first stateful entity* (be it stateful proxy or UAS/redirect) on
the call path, since retransmissions terminate there. The final responses
are from UAS to UAC, which is going to have an RTT much higher than the UAC
to first stateful proxy. In fact, in this case, the 100 response is the ONLY
place that Timestamp would be useful.

Other applications of timestamp (not sure what they are, though) might make
an end to end measurement useful.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 14:00:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23565
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 14:00:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 248BD44384; Wed, 31 Jan 2001 13:01:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51])
	by lists.bell-labs.com (Postfix) with ESMTP id A5DC844380
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 13:00:31 -0500 (EST)
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50])
	by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA04566;
	Wed, 31 Jan 2001 14:03:15 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21)
	id <CZ9KJC56>; Wed, 31 Jan 2001 13:56:47 -0500
Message-ID: <B65B4F8437968F488A01A940B21982BF9AB28D@DYN-EXCH-001.dynamicsoft.com>
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: "'William Marshall'" <wtm@research.att.com>, sip@lists.bell-labs.com
Subject: RE: [SIP] Some idea on Stateful SIP Proxy for Card Service
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 13:56:46 -0500



 

> -----Original Message-----
> From: William Marshall [mailto:wtm@research.att.com]
> Sent: Wednesday, January 17, 2001 7:47 AM
> To: sip@lists.bell-labs.com
> Subject: Re: [SIP] Some idea on Stateful SIP Proxy for Card Service
> 
> 
> P is clearly a back-to-back-UA, since it speaks SIP to
> both user B and terminal C.  However, its need to initiate
> a BYE doesn't fit the profile of a proxy.  Just a B2BUA.
> 
> In looking at various enhanced services, it is not clear
> to me that a "stateful proxy" will ever exist.  They will
> all be B2BUAs for some case or another.
> 

No.

You only want to be a B2BUA if that is the only way. The requirements for
fault tolerance and scale are much harder with a B2BUA (on part with a UA,
not a surprise). Stateful proxies can record-route and insert vias with
domain names, and the result is that these devices can still fail and the
calls can be recovered by routing the request/response to an alternate. Not
so for a B2BUA, which has state that now needs to be replicated in some way
(I realize State header is another possibility, its still just a form of
state replication).

Many services require only a stateful proxy. Many personal mobility services
fall into this category, as do all CPL types of services. This isn't
everything, but its a decent number.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 14:06:56 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23693
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 14:06:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 9082D4438A; Wed, 31 Jan 2001 13:07:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 4202144389
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 13:06:25 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA00355;
	Wed, 31 Jan 2001 14:06:10 -0500 (EST)
Message-ID: <3A786222.EBE6DAD1@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Cc: "'William Marshall'" <wtm@research.att.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] Some idea on Stateful SIP Proxy for Card Service
References: <B65B4F8437968F488A01A940B21982BF9AB28D@DYN-EXCH-001.dynamicsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 14:06:10 -0500
Content-Transfer-Encoding: 7bit

Jonathan Rosenberg wrote:
> 
> 

> 
> You only want to be a B2BUA if that is the only way. The requirements for
> fault tolerance and scale are much harder with a B2BUA (on part with a UA,
> not a surprise). Stateful proxies can record-route and insert vias with
> domain names, and the result is that these devices can still fail and the
> calls can be recovered by routing the request/response to an alternate. Not
> so for a B2BUA, which has state that now needs to be replicated in some way
> (I realize State header is another possibility, its still just a form of
> state replication).
> 
> Many services require only a stateful proxy. Many personal mobility services
> fall into this category, as do all CPL types of services. This isn't
> everything, but its a decent number.

As do firewall-type proxies.

Also, B2BUAs have a much harder time with loop detection, so it's harder
to "stack" them.

One also needs to consider the impact on signatures and authentication
in general. This can get pretty messy, depending on what fields the
B2BUA modifies in its newly generated messages. (This works well if the
B2BUA also appears as the trust entity to the next hop, but is iffy if
the original requestor is the one being authenticated.)

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 17:10:00 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26519
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 17:10:00 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id E69BD4435F; Wed, 31 Jan 2001 16:10:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
	by lists.bell-labs.com (Postfix) with ESMTP id 1B4364433A
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 16:09:28 -0500 (EST)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26])
	by mail-blue.research.att.com (Postfix) with ESMTP
	id 2739A4CE0E; Wed, 31 Jan 2001 17:09:13 -0500 (EST)
Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137])
	by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA28933;
	Wed, 31 Jan 2001 17:09:11 -0500 (EST)
From: William Marshall <wtm@research.att.com>
Received: (from wtm@localhost)
	by fish-ha.research.att.com (SGI-8.9.3/8.8.5) id RAA84628;
	Wed, 31 Jan 2001 17:09:58 -0500 (EST)
Message-Id: <200101312209.RAA84628@fish-ha.research.att.com>
To: jdrosen@dynamicsoft.com
Cc: sip@lists.bell-labs.com
Subject: RE: [SIP] Some idea on Stateful SIP Proxy for Card Service
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 17:09:58 -0500 (EST)


> -----Original Message-----
> From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
> To: "'William Marshall'" <wtm@research.att.com>, sip@lists.bell-labs.com
> Subject: RE: [SIP] Some idea on Stateful SIP Proxy for Card Service
> Date: Wed, 31 Jan 2001 13:56:46 -0500
> 
> > -----Original Message-----
> > From: William Marshall [mailto:wtm@research.att.com]
> > Sent: Wednesday, January 17, 2001 7:47 AM
> > To: sip@lists.bell-labs.com
> > Subject: Re: [SIP] Some idea on Stateful SIP Proxy for Card Service
> > 
> > 
> > P is clearly a back-to-back-UA, since it speaks SIP to
> > both user B and terminal C.  However, its need to initiate
> > a BYE doesn't fit the profile of a proxy.  Just a B2BUA.
> > 
> > In looking at various enhanced services, it is not clear
> > to me that a "stateful proxy" will ever exist.  They will
> > all be B2BUAs for some case or another.
> > 
> 
> No.
> 
> You only want to be a B2BUA if that is the only way. The requirements for
> fault tolerance and scale are much harder with a B2BUA (on part with a UA,
> not a surprise). Stateful proxies can record-route and insert vias with
> domain names, and the result is that these devices can still fail and the
> calls can be recovered by routing the request/response to an alternate. Not
> so for a B2BUA, which has state that now needs to be replicated in some way
> (I realize State header is another possibility, its still just a form of
> state replication).
> 
> Many services require only a stateful proxy. Many personal mobility services
> fall into this category, as do all CPL types of services. This isn't
> everything, but its a decent number.
> 
> -Jonathan R.

I think I agree with all the points you make, but disagree with the 
conclusion.

Consider a simple voicemail service, implemented by a service provider.
The UAS receives an INVITE, sends 180-Ringing, then 4xx/6xx and gives up.
The proxy changes the 4xx/6xx into a 302-Redirect with a Contact header
of the voicemail server.

But, a proxy can't do this.  So it is a B2BUA.  There is nothing about
state storage needed, nothing extra for fault tolerance and scale;
in fact this "proxy" is probably simpler than most "stateful proxies".
But its need to change the response from 4xx/6xx to 3xx makes it a B2BUA.

Second example is any kind of subscription-based service to the proxy.
Subscriptions expire.  The proxy, if it is maintaining any call state
as a "stateful proxy", will want to terminate any pending connections
rather than continue to provide free service.  So it generates a BYE.
Not a proxy any longer, now a B2BUA.  But not any more complex than
any other stateful proxy, (except possibly for remembering the Record-
Route header value for the active sessions).  The fault tolerance and
scale problems are the same as the stateful proxy.

I'm not familiar with CPL, so maybe those can be done with stateful proxies.
Can a CPL type of service re-write error responses, like a 4xx to a 3xx?
Can a CPL type of service re-write header values, like a Contact header
for forwarding?  Can a CPL type of service look at the SDP to pick an
appropriate destination based on the media being requested?  All simple
transformations, but all require a B2BUA.

Maybe I overstated the case by saying "a 'stateful proxy' will never
exist".  My suspician is that a typical session will have a proxy at each
end (providing service for the UAC/UAS), and several stateless proxies
in the middle.  My suspician is still that the proxy providing service
to the endpoints will not meet the restrictions of a proxy, and will
need to be classified a B2BUA.  But this does not make this element
any more complex than a "stateful proxy".

Bill Marshall
wtm@research.att.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 17:26:52 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26815
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 17:26:52 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 90AC744377; Wed, 31 Jan 2001 16:27:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by lists.bell-labs.com (Postfix) with ESMTP id 17EB14435F
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 16:26:19 -0500 (EST)
Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA04494;
	Wed, 31 Jan 2001 14:26:16 -0800 (PST)
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53])
	by mira-sjc5-7.cisco.com (Mirapoint)
	with ESMTP id AAT09874;
	Wed, 31 Jan 2001 14:26:04 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA29379; Wed, 31 Jan 2001 14:26:04 -0800 (PST)
From: Michael Thomas <mat@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14968.37115.842736.948940@thomasm-u1.cisco.com>
To: William Marshall <wtm@research.att.com>
Cc: jdrosen@dynamicsoft.com, sip@lists.bell-labs.com
Subject: RE: [SIP] Some idea on Stateful SIP Proxy for Card Service
In-Reply-To: <200101312209.RAA84628@fish-ha.research.att.com>
References: <200101312209.RAA84628@fish-ha.research.att.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
 @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
 bUcI'1!
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 14:26:03 -0800 (PST)
Content-Transfer-Encoding: 7bit


I'm sort of on the fence about this one, but one
thing that bugs me -- maybe unduly -- is whether a
B2BUA must be party to the SDP and other end to
end kinds of things. If the answer is yes, I have
a lot of problems with any widespread usage of
B2BUA's if from nothing else an end to end privacy
standpoint.

There are certainly some things that are quite
appropriately modeled as a B2BUA -- an anoymizer
is an obvious situation where the e2e'ness is a
bug not a feature -- but I'm sort of skeptical
about the widespread use of B2BUA's. It seems like
it's just giving into the PSTN access tandem urge
which is... bad.

Live free [of network state], or die.

		 Mike

William Marshall writes:
 > 
 > > -----Original Message-----
 > > From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
 > > To: "'William Marshall'" <wtm@research.att.com>, sip@lists.bell-labs.com
 > > Subject: RE: [SIP] Some idea on Stateful SIP Proxy for Card Service
 > > Date: Wed, 31 Jan 2001 13:56:46 -0500
 > > 
 > > > -----Original Message-----
 > > > From: William Marshall [mailto:wtm@research.att.com]
 > > > Sent: Wednesday, January 17, 2001 7:47 AM
 > > > To: sip@lists.bell-labs.com
 > > > Subject: Re: [SIP] Some idea on Stateful SIP Proxy for Card Service
 > > > 
 > > > 
 > > > P is clearly a back-to-back-UA, since it speaks SIP to
 > > > both user B and terminal C.  However, its need to initiate
 > > > a BYE doesn't fit the profile of a proxy.  Just a B2BUA.
 > > > 
 > > > In looking at various enhanced services, it is not clear
 > > > to me that a "stateful proxy" will ever exist.  They will
 > > > all be B2BUAs for some case or another.
 > > > 
 > > 
 > > No.
 > > 
 > > You only want to be a B2BUA if that is the only way. The requirements for
 > > fault tolerance and scale are much harder with a B2BUA (on part with a UA,
 > > not a surprise). Stateful proxies can record-route and insert vias with
 > > domain names, and the result is that these devices can still fail and the
 > > calls can be recovered by routing the request/response to an alternate. Not
 > > so for a B2BUA, which has state that now needs to be replicated in some way
 > > (I realize State header is another possibility, its still just a form of
 > > state replication).
 > > 
 > > Many services require only a stateful proxy. Many personal mobility services
 > > fall into this category, as do all CPL types of services. This isn't
 > > everything, but its a decent number.
 > > 
 > > -Jonathan R.
 > 
 > I think I agree with all the points you make, but disagree with the 
 > conclusion.
 > 
 > Consider a simple voicemail service, implemented by a service provider.
 > The UAS receives an INVITE, sends 180-Ringing, then 4xx/6xx and gives up.
 > The proxy changes the 4xx/6xx into a 302-Redirect with a Contact header
 > of the voicemail server.
 > 
 > But, a proxy can't do this.  So it is a B2BUA.  There is nothing about
 > state storage needed, nothing extra for fault tolerance and scale;
 > in fact this "proxy" is probably simpler than most "stateful proxies".
 > But its need to change the response from 4xx/6xx to 3xx makes it a B2BUA.
 > 
 > Second example is any kind of subscription-based service to the proxy.
 > Subscriptions expire.  The proxy, if it is maintaining any call state
 > as a "stateful proxy", will want to terminate any pending connections
 > rather than continue to provide free service.  So it generates a BYE.
 > Not a proxy any longer, now a B2BUA.  But not any more complex than
 > any other stateful proxy, (except possibly for remembering the Record-
 > Route header value for the active sessions).  The fault tolerance and
 > scale problems are the same as the stateful proxy.
 > 
 > I'm not familiar with CPL, so maybe those can be done with stateful proxies.
 > Can a CPL type of service re-write error responses, like a 4xx to a 3xx?
 > Can a CPL type of service re-write header values, like a Contact header
 > for forwarding?  Can a CPL type of service look at the SDP to pick an
 > appropriate destination based on the media being requested?  All simple
 > transformations, but all require a B2BUA.
 > 
 > Maybe I overstated the case by saying "a 'stateful proxy' will never
 > exist".  My suspician is that a typical session will have a proxy at each
 > end (providing service for the UAC/UAS), and several stateless proxies
 > in the middle.  My suspician is still that the proxy providing service
 > to the endpoints will not meet the restrictions of a proxy, and will
 > need to be classified a B2BUA.  But this does not make this element
 > any more complex than a "stateful proxy".
 > 
 > Bill Marshall
 > wtm@research.att.com
 > 
 > _______________________________________________
 > This list is for continuing development of the SIP protocol.
 > The sip-implementer's list is the place to discuss implementation,
 > and to receive advice on understanding existing sip.
 > To subscribe to it, send mail to majordomo@cs.columbia.edu with
 > "subscribe sip-implementors" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 17:30:09 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26955
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 17:30:09 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 6D4AD44384; Wed, 31 Jan 2001 16:30:09 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141])
	by lists.bell-labs.com (Postfix) with ESMTP id 70DF344383
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 16:29:53 -0500 (EST)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA03207; Wed, 31 Jan 2001 17:29:38 -0500 (EST)
Received: from mhammer-nt.cisco.com (hrn3-dhcp-161-44-93-108.cisco.com [161.44.93.108])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AAE13300;
	Wed, 31 Jan 2001 17:29:32 -0500 (EST)
Message-Id: <4.3.2.7.2.20010131172705.00b53800@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Jaime Jimenez <jjimenez@tachion.com>, sip@lists.bell-labs.com
From: hammer michael <mhammer@cisco.com>
Subject: RE: [SIP] Announcements in SIP
In-Reply-To: <5E7936641DC2D411B89900D0B7B92FBB1AC0CF@TNNT3>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 17:36:49 -0800

I second the idea to try to filter out PSTN inefficiencies if 
possible.  That said, would packetized one-shot (voice-mail or data) 
responses be preferred over streamed connections?

Another thought to keep in the back of the mind, you might also want to 
consider the possibility that the user or the terminal is not native to the 
location of the proxy.  Put another way, if the announcement played to me 
is in Chinese, it would do me no good.  A data message might be easier to 
translate, but would present the same problems.  Any 3G mobile-related 
solutions?

Mike Hammer


At 09:55 AM 01/25/2001 -0500, Jaime Jimenez wrote:

>I am new to this list and I have a quick question on this item.
>
>Are we looking to provide "in-band" Announcements for what traditionally 
>been call "network announcements?"  In the US PSTN we are required to 
>provide "answer supervision" (meaning to answer the call) before a 
>"customer" announcement can be played to the calling party. So if the call 
>is queued, then the call needs to be answered before a message can be provided.
>
>Having said that, there are other scenarios where the "network" can 
>provide recorded announcements (congestion, etc.) that are provided, but 
>letting the end system map that locally maybe the best approach.
>
>Jaime
>
>If it can be done (getting around the 4xx response issue), it look great.
>Rather than recreating the bugs (I mean features :-) of the PSTN [sending
>aural signaling in-band as "early media"], we provide useful solutions to
>end users [providing informative responses, using local resources when
>possible or network resources if necessary].
>
> > On seeing a 404 response, an end UA *may* choose to use the information in
> > the CallProgress-Info header if it is not capable of providing local
> > annoucements, otherwise, it could render to the user the information
> > provided in the CallProgress-Info header. How does this look?
> >
>[snip]
>



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 17:48:54 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27175
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 17:48:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id D4B3244377; Wed, 31 Jan 2001 16:49:05 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20])
	by lists.bell-labs.com (Postfix) with ESMTP id 9D54A44373
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 16:48:40 -0500 (EST)
Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191])
	by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA24489;
	Wed, 31 Jan 2001 17:48:22 -0500 (EST)
Message-ID: <3A789636.E50C6A15@cs.columbia.edu>
From: "Henning G. Schulzrinne" <hgs@cs.columbia.edu>
Organization: Dept. of Computer Science, Columbia University
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Thomas <mat@cisco.com>
Cc: William Marshall <wtm@research.att.com>, jdrosen@dynamicsoft.com,
        sip@lists.bell-labs.com
Subject: Re: [SIP] Some idea on Stateful SIP Proxy for Card Service
References: <200101312209.RAA84628@fish-ha.research.att.com> <14968.37115.842736.948940@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 17:48:22 -0500
Content-Transfer-Encoding: 7bit

The answering service model can also easily be accomplished by a
("virtual") UAS that is parallel-forked in the proxy. Thus, even for
those services, a B2BUA is not strictly necessary.

B2BUA, like proxies, can, but don't have to modify SDP. Proxies serving
as part of NAT ALGs may need to, for example.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 18:11:53 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27592
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 18:11:53 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 3DAAD4435F; Wed, 31 Jan 2001 17:12:06 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.199.141])
	by lists.bell-labs.com (Postfix) with ESMTP id 5420A4433A
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 17:11:46 -0500 (EST)
Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.199.157]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA03731; Wed, 31 Jan 2001 18:11:31 -0500 (EST)
Received: from mhammer-nt.cisco.com (hrn3-dhcp-161-44-93-108.cisco.com [161.44.93.108])
	by cia.cisco.com (Mirapoint)
	with ESMTP id AAF00419;
	Wed, 31 Jan 2001 18:11:30 -0500 (EST)
Message-Id: <4.3.2.7.2.20010131181302.00b70100@cia.cisco.com>
X-Sender: mhammer@cia.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
To: Rick Dean <siplist@fdd.com>, "Roy, Radhika R, ALCOO" <rrroy@att.com>
From: hammer michael <mhammer@cisco.com>
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
Cc: sip@lists.bell-labs.com
In-Reply-To: <20010130101550.A11772@fdd.com>
References: <E5B80B001D76D211879C00E02910776107D67CA1@njc240po05.mt.att.com>
 <E5B80B001D76D211879C00E02910776107D67CA1@njc240po05.mt.att.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 18:18:47 -0800

Having worked for a few years in a mobile standards group, don't even walk 
in the door with this called "handoff."  You would instantly lose 
credibility that you knew what you were attempting to do.  I assume that 
SIP is not excluding itself from the mobile network space.  There are 
plenty of other closely related feature names that with an appropriate 
modifier would not intentionally cause confusion.

Mike


At 10:15 AM 01/30/2001 -0600, Rick Dean wrote:

>Thank you two for the first non-comical name suggestion.
>We are not in love with the handoff name, and if the SIP community
>would let us title the method TRANSFER, we would be
>delighted.
>
>Supervised transfer encompases the conferenceing stage,
>possible B2BUA'ing, and other things which is broader than our draft.
>HANDOFF is the quick movement of one end of a two-party call leg.
>
>We read the draft Pal Calhoun referenced:
>ftp://ftp.isi.edu/internet-drafts/draft-manner-seamoby-terms-00.txt
>It has an impressive number of definitions.  There seem to be
>many kinds of handover/handoff.   Our draft is
>the best map for a SIP-layer handoff.
>
>We would like to wait for feedback at the Dallas interim meeting
>before re-releasing it with a new name.
>
>--
>Rick
>
>On Mon, Jan 29, 2001 at 08:40:29PM -0500, Roy, Radhika R, ALCOO wrote:
> > TRANFER or similar term seems to be more acceptable to me/Radhika
> >
> > -----Original Message-----
> > From: Sean Olson [mailto:sean.olson@ericsson.com]
> > Sent: Monday, January 29, 2001 2:35 PM
> > To: Roy, Radhika R, ALCOO
> > Cc: Patrice Calhoun; ???; Rick Dean; Rohan Mahy; sip@lists.bell-labs.com
> > Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
> >
> >
> > The name can be confusing, I agree. But as with all
> > specifications, you need to read them in the appropriate
> > context. I personally find HANDOFF completely apropos for
> > this usage because it is a SIP method and because the
> > introduction in the draft does a good job of establishing
> > the scope and meaning of the method. If HANDOFF is
> > taboo, how about "TRANSFER"? Nevermind the confusing
> > part about the transfer draft defining REFER and the handoff
> > draft defining REFER :)
> >
> > my two cents
> > /sean
> >
> > Roy, Radhika R, ALCOO wrote:
> >
> > > Yes, as PatC pointed out, the term "HANDOFF" is creating a constant
> > > confusion.
> > > I, like many others, also point this to the WG for consideration.
> > >
> > > Radhika R. Roy
> > > AT&T
> > >
> > > -----Original Message-----
> > > From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com]
> > > Sent: Sunday, January 28, 2001 1:46 PM
> > > To: ???
> > > Cc: Rick Dean; Rohan Mahy; sip@lists.bell-labs.com
> > > Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
> > >
> > >
> > > Ahhh, I see that the misuse of terminology is biting this WG in the a..
> > >
> > > This isn't a handoff as you, or I, or anyone else involved in mobility
> > > management understands it. It is rather a form of call transfer. You are
> > > correct that the handoff will occur at the GGSN/SGSN.
> > >
> > > I have asked that the WG refrain from using the term handoff, or 
> handover,
> > > given that the mobility folks will have serious issues with it (as they
> > have
> > > had with SIP Mobility, when it fact it is really portability). However,
> > the
> > > WG
> > > does not seem to be willing to listen to our requests :(
> > >
> > > I suppose we will simply have to deal with the constant confusion we are
> > > creating in the marketplace by abusing terminology.
> > >
> > > PatC
> > >
> > >> Dear all.
> > >>
> > >> I am some curious about HANDOFF method.
> > >> I think, HANDOFF method is required when SIP terminal moves from one
> > >
> > > network
> > >
> > >> to other network.
> > >>
> > >> In 3GPP TR23.821, the sentense,
> > >> " As a consequence, the behaviour of the multimedia call control server
> > >> (CSCF) can be the same whatever the access technology (radio or
> > >
> > > wired-line).
> > >
> > >> Multimedia call control/mobility management shall not be aware of the
> > >
> > > access
> > >
> > >> technology: the multimedia Call Control (CSCF) does not handle notions
> > >
> > > such
> > >
> > >> as Hand-Over, RA, "
> > >>
> > >> It means that handoff is the problem of GGSN and SGSN not CSCF which
> > >
> > > support
> > >
> > >> SIP protocol. It is not the business of CSCF.
> > >>
> > >> Therefore I think HANDOFF method is not required at least 3GPP.
> > >>
> > >> What do you think about this?
> > >>
> > >
> > >
> > >
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementer's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > "subscribe sip-implementors" in the body.
> > >
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementer's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > "subscribe sip-implementors" in the body.
> >
> > _______________________________________________
> > This list is for continuing development of the SIP protocol.
> > The sip-implementer's list is the place to discuss implementation,
> > and to receive advice on understanding existing sip.
> > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > "subscribe sip-implementors" in the body.
>
>_______________________________________________
>This list is for continuing development of the SIP protocol.
>The sip-implementer's list is the place to discuss implementation,
>and to receive advice on understanding existing sip.
>To subscribe to it, send mail to majordomo@cs.columbia.edu with
>"subscribe sip-implementors" in the body.



_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.


From sip-admin@lists.bell-labs.com  Wed Jan 31 19:39:55 2001
Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28907
	for <sip-archive@odin.ietf.org>; Wed, 31 Jan 2001 19:39:55 -0500 (EST)
Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1])
	by lists.bell-labs.com (Postfix) with ESMTP
	id 5997D4434A; Wed, 31 Jan 2001 18:40:07 -0500 (EST)
Delivered-To: sip@lists.bell-labs.com
Received: from fdd.com (24-148-46-207.na.21stcentury.net [24.148.46.207])
	by lists.bell-labs.com (Postfix) with ESMTP id 4EE3E4433A
	for <sip@lists.bell-labs.com>; Wed, 31 Jan 2001 18:39:12 -0500 (EST)
Received: (from siplist@localhost)
	by fdd.com (8.10.1/8.10.1) id f110cxP18186;
	Wed, 31 Jan 2001 18:38:59 -0600 (CST)
From: Rick Dean <siplist@fdd.com>
To: hammer michael <mhammer@cisco.com>
Cc: "Roy, Radhika R, ALCOO" <rrroy@att.com>, sip@lists.bell-labs.com
Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
Message-ID: <20010131183859.A10391@fdd.com>
References: <E5B80B001D76D211879C00E02910776107D67CA1@njc240po05.mt.att.com> <E5B80B001D76D211879C00E02910776107D67CA1@njc240po05.mt.att.com> <20010130101550.A11772@fdd.com> <4.3.2.7.2.20010131181302.00b70100@cia.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <4.3.2.7.2.20010131181302.00b70100@cia.cisco.com>; from mhammer@cisco.com on Wed, Jan 31, 2001 at 06:18:47PM -0800
Sender: sip-admin@lists.bell-labs.com
Errors-To: sip-admin@lists.bell-labs.com
X-BeenThere: sip@lists.bell-labs.com
X-Mailman-Version: 2.0beta6
Precedence: bulk
List-Help: <mailto:sip-request@lists.bell-labs.com?subject=help>
List-Post: <mailto:sip@lists.bell-labs.com>
List-Subscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=subscribe>
List-Id: IETF SIP Mailing List <sip.lists.bell-labs.com>
List-Unsubscribe: <http://lists.bell-labs.com/mailman/listinfo/sip>, <mailto:sip-request@lists.bell-labs.com?subject=unsubscribe>
List-Archive: http://lists.bell-labs.com/pipermail/sip/
Date: Wed, 31 Jan 2001 18:38:59 -0600


MOVE is my current favorite,
with "move-to:" and "moved-from:"

Something with mixed case would suit me.  Possibly
four letters and begins with "D", hmmm... :-)

--
Rick Dean
3Com

On Wed, Jan 31, 2001 at 06:18:47PM -0800, hammer michael wrote:
> Having worked for a few years in a mobile standards group, don't even walk 
> in the door with this called "handoff."  You would instantly lose 
> credibility that you knew what you were attempting to do.  I assume that 
> SIP is not excluding itself from the mobile network space.  There are 
> plenty of other closely related feature names that with an appropriate 
> modifier would not intentionally cause confusion.
> 
> Mike
> 
> 
> At 10:15 AM 01/30/2001 -0600, Rick Dean wrote:
> 
> >Thank you two for the first non-comical name suggestion.
> >We are not in love with the handoff name, and if the SIP community
> >would let us title the method TRANSFER, we would be
> >delighted.
> >
> >Supervised transfer encompases the conferenceing stage,
> >possible B2BUA'ing, and other things which is broader than our draft.
> >HANDOFF is the quick movement of one end of a two-party call leg.
> >
> >We read the draft Pal Calhoun referenced:
> >ftp://ftp.isi.edu/internet-drafts/draft-manner-seamoby-terms-00.txt
> >It has an impressive number of definitions.  There seem to be
> >many kinds of handover/handoff.   Our draft is
> >the best map for a SIP-layer handoff.
> >
> >We would like to wait for feedback at the Dallas interim meeting
> >before re-releasing it with a new name.
> >
> >--
> >Rick
> >
> >On Mon, Jan 29, 2001 at 08:40:29PM -0500, Roy, Radhika R, ALCOO wrote:
> > > TRANFER or similar term seems to be more acceptable to me/Radhika
> > >
> > > -----Original Message-----
> > > From: Sean Olson [mailto:sean.olson@ericsson.com]
> > > Sent: Monday, January 29, 2001 2:35 PM
> > > To: Roy, Radhika R, ALCOO
> > > Cc: Patrice Calhoun; ???; Rick Dean; Rohan Mahy; sip@lists.bell-labs.com
> > > Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
> > >
> > >
> > > The name can be confusing, I agree. But as with all
> > > specifications, you need to read them in the appropriate
> > > context. I personally find HANDOFF completely apropos for
> > > this usage because it is a SIP method and because the
> > > introduction in the draft does a good job of establishing
> > > the scope and meaning of the method. If HANDOFF is
> > > taboo, how about "TRANSFER"? Nevermind the confusing
> > > part about the transfer draft defining REFER and the handoff
> > > draft defining REFER :)
> > >
> > > my two cents
> > > /sean
> > >
> > > Roy, Radhika R, ALCOO wrote:
> > >
> > > > Yes, as PatC pointed out, the term "HANDOFF" is creating a constant
> > > > confusion.
> > > > I, like many others, also point this to the WG for consideration.
> > > >
> > > > Radhika R. Roy
> > > > AT&T
> > > >
> > > > -----Original Message-----
> > > > From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com]
> > > > Sent: Sunday, January 28, 2001 1:46 PM
> > > > To: ???
> > > > Cc: Rick Dean; Rohan Mahy; sip@lists.bell-labs.com
> > > > Subject: Re: [SIP] draft-ietf-sip-handoff-00pre8.txt
> > > >
> > > >
> > > > Ahhh, I see that the misuse of terminology is biting this WG in the a..
> > > >
> > > > This isn't a handoff as you, or I, or anyone else involved in mobility
> > > > management understands it. It is rather a form of call transfer. You are
> > > > correct that the handoff will occur at the GGSN/SGSN.
> > > >
> > > > I have asked that the WG refrain from using the term handoff, or 
> > handover,
> > > > given that the mobility folks will have serious issues with it (as they
> > > have
> > > > had with SIP Mobility, when it fact it is really portability). However,
> > > the
> > > > WG
> > > > does not seem to be willing to listen to our requests :(
> > > >
> > > > I suppose we will simply have to deal with the constant confusion we are
> > > > creating in the marketplace by abusing terminology.
> > > >
> > > > PatC
> > > >
> > > >> Dear all.
> > > >>
> > > >> I am some curious about HANDOFF method.
> > > >> I think, HANDOFF method is required when SIP terminal moves from one
> > > >
> > > > network
> > > >
> > > >> to other network.
> > > >>
> > > >> In 3GPP TR23.821, the sentense,
> > > >> " As a consequence, the behaviour of the multimedia call control server
> > > >> (CSCF) can be the same whatever the access technology (radio or
> > > >
> > > > wired-line).
> > > >
> > > >> Multimedia call control/mobility management shall not be aware of the
> > > >
> > > > access
> > > >
> > > >> technology: the multimedia Call Control (CSCF) does not handle notions
> > > >
> > > > such
> > > >
> > > >> as Hand-Over, RA, "
> > > >>
> > > >> It means that handoff is the problem of GGSN and SGSN not CSCF which
> > > >
> > > > support
> > > >
> > > >> SIP protocol. It is not the business of CSCF.
> > > >>
> > > >> Therefore I think HANDOFF method is not required at least 3GPP.
> > > >>
> > > >> What do you think about this?
> > > >>
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > This list is for continuing development of the SIP protocol.
> > > > The sip-implementer's list is the place to discuss implementation,
> > > > and to receive advice on understanding existing sip.
> > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > > "subscribe sip-implementors" in the body.
> > > >
> > > > _______________________________________________
> > > > This list is for continuing development of the SIP protocol.
> > > > The sip-implementer's list is the place to discuss implementation,
> > > > and to receive advice on understanding existing sip.
> > > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > > "subscribe sip-implementors" in the body.
> > >
> > > _______________________________________________
> > > This list is for continuing development of the SIP protocol.
> > > The sip-implementer's list is the place to discuss implementation,
> > > and to receive advice on understanding existing sip.
> > > To subscribe to it, send mail to majordomo@cs.columbia.edu with
> > > "subscribe sip-implementors" in the body.
> >
> >_______________________________________________
> >This list is for continuing development of the SIP protocol.
> >The sip-implementer's list is the place to discuss implementation,
> >and to receive advice on understanding existing sip.
> >To subscribe to it, send mail to majordomo@cs.columbia.edu with
> >"subscribe sip-implementors" in the body.
> 
> 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to majordomo@cs.columbia.edu with
"subscribe sip-implementors" in the body.